cmake

[William A. Hoffman]

At 01:51 PM 6/8/2006, Thomas Zander wrote:
>On Thursday 8 June 2006 18:40, Alexander Neundorf wrote:
>> > The issue is that cmake tries to make all subtrees behave like one
>> > tree while using a lot of makefiles and with the limitations of POSIX
>> > make this is just a recipe for failure.  This is the design flaw I'm
>> > looking at.
>>
>> I handles trees as one big project and since the apps and libs in the
>> tree depend on each other I don't see the design flaw in this approach.
>
>The fact that it handles trees as one big project and thus has a different 
>definition of 'subproject' as make and unsermake had is the problem 
>indeed.
>
>That you don't see that as a problem only means that you misunderstood the 
>requirements KDE developers[1] have of their buildsystem.
>
>
>1) I hardly can speak for all developers, but all people I spoke to saw 
>this issue as a problem.

I don't think this is a design flaw.   Building targets without doing the extra
depend steps is there now with target/fast from the top-level of the tree.  This
will work in cmake 2.4.2.   In 2.4.3 (and cvs right now), there is an install/fast
target that will just install and not try to build, also the target/fast targets
are in the sub project makefiles not just at the top-level.

There are some questions as to what the default should be in a sub-directory.
Should running make in a sub-directory default to the fast or safe target?   
It all depends on what you are doing which one makes more sense.   It can be changed
to the one that makes the most sense.  Maybe from a sub-directory make target/safe
will build all the targets that depend on it, and make target or make will build the
target/fast or target*/fast in the current directory.  

There is one more issue.  That is the issue that if you change a CMakeListstxt file
cmake has to process the whole tree.   There is not much that can be done about this,
as variables may change or be used that are from other CMakeListstxt files.   However,
I don't think the development process involves changing the CMakeLists.txt files over
and over.  You add a source file or two, then you debug them.   So, changing a single
source file needs to be fast, and the fast targets address this.   Changing, or profiling 
the automoc stuff may help speed this up.  

Is this a complete picture of the issue?

-Bill