Am Tue, 11 May 2010 13:23:06 +0400
schrieb Konstantin Tokarev <annu...@yandex.ru>:
> Yes, I know there're some large projects that use GNU make as build
> system, e.g. commercial quantum package Molpro. But it's the way of
> developing your own build system instead of using/improving existing
> one (I don't call GNU make itself a "build system" because it has too
> few built-in facilities comparing to CMake or autotools)
Most of the built-in facilities are unfortunately of little help
because of all the specials we have in the requirements even for
seemingly innocent stuff like compiling C/C++ and linking
objects/libraries. For example:
- We link libraries against other libraries in other locations (that
complete solver concept).
- We link libraries against other libraries in different locations from
where they are at runtime.
- There is more than one possible runtime location for each lib ("three
layer office" etc.)
This leads to some "interesting" constructions, for example on OSX
where the linker needs to know about the runtime locations of libs it
links against. Assuming this could simply be abstracted away with
built-in CMake facilities is IMHO quite naive. And there are certainly
a lot of other pitfalls to be found, so that the assumption that it
would be easier to use CMake just isnt valid.
In addition, for stuff like our own localization toolchain etc. we cant
possibly hope for any support from CMake, so it makes little difference.
Best Regards,
Bjoern
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.org
For additional commands, e-mail: dev-h...@openoffice.org
