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...@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.jack...@bluequartz.net
BlueQuartz Software Dayton, Ohio
_______________________________________________
Powered by www.kitware.com
Visit other Kitware open-source projects at
http://www.kitware.com/opensource/opensource.html
Please keep messages on-topic and check the CMake FAQ at:
http://www.cmake.org/Wiki/CMake_FAQ
Follow this link to subscribe/unsubscribe:
http://www.cmake.org/mailman/listinfo/cmake
