[CMake] makefile to CMakeLists.txt, possible?

[Alexander Neundorf]

On Thursday 02 September 2010, Alexander Neundorf wrote:
> On Thursday 02 September 2010, Raymond Wan wrote:
> > Hi Chiheng,
> >
> > On Thu, Sep 2, 2010 at 16:15, Chiheng Xu <chiheng.xu at gmail.com> wrote:
> > > CMake is a very great tool.    But its drawback is also obvious.    It
> > > will consume large amount of time to generate Makefiles every time you
> > > want to build,  especially for ultra large projects.   Building can be
> > > parallelized, but the CMaking, like runing configure scripts, can't be
> > > parallelized.   So, the "caching" of Makefiles seems benefitial  for
> > > current and future mutil-cores systems.
> > >
> > > Normal developers seldomly touch CMakeLists.txt.  So,  in very rare
> > > condition, you need to regenerate the Makefiles.
> >
> > As someone who just started using CMake (quite literally a few weeks
> > ago), I'm somewhat interested in your arguments.  Personally, I don't
> > see many drawbacks and I must be missing something if they are
> > "obvious".
>
> Generated makefiles can't be portable e.g. because they contain include
> paths and paths to libraries which will be linked which can differ on each
> system. Also, the generated makefiles contain calls to cmake e.g. for the
> progress report.
> Also, it is quite common to use cmake -E for cross platform commands e.g.
> in add_custom_command() or add_custom_target(), which results in rules in
> the makefiles which call cmake to do something,  e.-g. copy a file or
> something.
>
> > It is true that while developing software, using CMake requires an
> > extra step.  For example, when you add a C++ source file, you'll need
> > to run cmake and then make.
>
> If cmake has already generated makefiles for you, you don't need to invoke
> it manually again after editing CMakeLists.txt, the generated makefiles
> include this dependency and rerun cmake automatically for you.
>
>
> Nevertheless, some way to make something in cmake parallel would be nice
> :-) But at least for me it's not obvious how to do that.

First step would be to profile where cmake spends most of the time.

I would guess that there is a lot of I/O (where running multiple threads 
probably would not help much), and probably string functions like strcmp(), 
strlen() and the std::string ctor.
Internally cmake uses mostly std::strings, but a lot of functions in cmake 
take char* strings as parameters, and often then convert them back to 
std::strings. Adding variants which directly take std::string might make 
things faster (IIRC std::strings have explicit lengths so a lot of strlen() 
calls should be saved and comparing two strings should be also faster).

Beside that, maybe in the final generate-step writing of the output files 
could be parallelized (like having one thread with a job queue to write one 
file after the other while the main thread keeps processing), but this is 
probably IO-bound anyway.

Alex