Rodolfo Schulz de Lima wrote:
So, apart of forking, a build system that wants to be better than cmake
should reimplement 90% of cmake's features, just to add those 10% missing?
Kind of. Not really 90%, but more like 60-70%. It would first have to:
* gotten dependencies correct (this is really hard).
* be fast in every aspect (hard without coding it in c/c++).
* be multi-platform.
Without those three, nothing else matters. Once those are okay, you
need to:
* support a couple of languages (say c++ and java).
* have an easy to extend (and well defined) framework.
If, say, swig is not supported, but the framework is
defined, someone else should be able to write a module for it.
* support a couple of common IDEs and compilers (mainly
gcc and msvc). Others will appear as need arises.
* have support to find files on disk (includes, libs, exes).
* have decent docs or at least a bunch of examples.
* be well supported with a mailing list
(and not a dead one like jam).
Getting all that right is *HARD* and can easily be a full-time job.
Most of cmake competitors have not yet full-filled all of the above.
Ergo, why cmake still rules.
Additional components like cpack or ctest are a plus, but they are not
a major reason for sticking with cmake.
While a large amount of cmake's modules is nice when you start with it,
it is not a deal breaker if the framework is good (and a good OO
framework should be better than what cmake does with FIND_PACKAGE).
Things that would also earn tons of brownie points would be:
* smaller than cmake (both to compile and distribute).
* good for cross-compilation.
--
Gonzalo Garramuño
[EMAIL PROTECTED]
AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy
_______________________________________________
CMake mailing list
[email protected]
http://www.cmake.org/mailman/listinfo/cmake
