On 05/11/2010 11:30 AM, Konstantin Tokarev wrote:
Please read the wiki article, it seems you don't know which "other
inherent faults" I'm talking about. Recursive systems have *inherent*
disadvantages and overcoming them needs to switch to a non-recursive
system. This is not related to dependencies. CMake has a
non-recursive element (the export to the backends), so everything
that can be evaluated here (dependencies) can be done without the
disadvantages of a recursive build system. But the build itself is
recursive, so everything that happens at build time shows the usual
disadvantages as described in the wiki.
...
The goal is to have makefiles of sub units that can be combined with
each other so that they produce output in the same workdir. In our
GNUMake based approach all you have to do for that is include the
makefiles of the parts you want to combine, whereever they reside. In
CMake we couldn't find a way to achieve that without changing the
CMake makefiles each time we wanted to combine them in a different
way and this is unacceptable for us.
In CMake you can also include other cmake sources into CMakeLists.txt,
just as in GNU make
Sure, but CMake does not have target local variables, dynamic evaluation
etc. that make that usable in a large scale project. I you look on the
makefiles in our CWS gnumake2, you might get an impression of what I'm
talking about. By keeping all associated variables local to the targets
that they describe, we implemented a kind of namespacing that allows us
to combine arbitrary makefiles into one process. How do you define
variables in CMake that are local to a particular target? I didn't find
that.
CMake doesn't need that as it is a recursive system. But again that is
the limitation that we want to get rid of. If you try to add
non-recursive elements to CMake (like including makefiles in makefiles)
you see that it lacks the necessary concepts to use that in a large
scale project. That's not bad - it's just not what we are looking for.
Regards,
Mathias
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[email protected]".
I use it for the OOo lists and only rarely read other mails sent to it.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
