[CMake] makefile to CMakeLists.txt, possible?

[Michael Jackson]

On Sep 3, 2010, at 1:45 PM, Alexander Neundorf wrote:

> 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

I was just thinking about this the other day. One specialized area  
that would be helped by threads would be in some project configuration  
where we have CMake looking for about 20 different headers and another  
20 or so types. Generally none of this is dependent on the other.
   Something where I could have a  
"parallel_section()"/"end_parallel_section()" section where I could  
list all the tests and CMake could run them in parallel if the builder  
allows it or there are enough cpu resources available.
   Just a thought.
___________________________________________________________
Mike Jackson                      www.bluequartz.net
Principal Software Engineer       mike.jackson at bluequartz.net
BlueQuartz Software               Dayton, Ohio