[CMake] Re: premake build system

Gonzalo Garramuño ggarra at advancedsl.com.ar
Mon Dec 17 13:22:52 EST 2007


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
ggarra at advancedsl.com.ar

AMD4400 - ASUS48N-E
GeForce7300GT
Xubuntu Gutsy


More information about the CMake mailing list