CMake Proposal

simo idra at
Wed Feb 24 18:13:15 MST 2010

On Thu, 2010-02-25 at 11:01 +1100, Andrew Bartlett wrote:
> On Thu, 2010-02-25 at 10:33 +1100, tridge at wrote:
> >  > I haven't found a test infrastructure in waf I didn't find information how 
> >  > they insure that a compiler and a platform is really supported.
> > 
> > I really don't want to change away from our current test
> > infrastructure. 
> Tridge,
> I think Andreas meant the selftest infrastructure for waf, not our
> selftest infrastructure. 

Yes, the reason why I prefer CMake is that there is a team behind it
that offered to help and a track that proves cmake works with very big
projects (like KDE).
Selftest assure that the tool work under many conditions, many of them
we won't find if we just run waf in our build farm because we do not
stress some feature yet.

I also do not agree that making special rules for compilers and linkers
is just easy. There is a good reason tools like cmake and libtool have
been invented, now I don't like how libtool operates, but I certainly
appreciate that we will not have to care about these details.

They have been quite a distraction all over the time and have
conditioned our ability to make libraries in the past.

The reason why I am not excited about waf is that it seem we are going
to just rebuild the same completely custom and intricate build system we
have now just with a different tool. What I appreciate is that waf have
at least some more people around it so it is not some completely unknown
to everyone else.

For the rest it seem to me that the preference toward waf boils down to
just one thing:
- waf is written in python and this seem a more appealing idea than
cmake's own language

What worries me though is that any deficiency is put aside with a "not
important" label, while the same points where immediately asked like
they were strictly required when we proposed CMake.

Everything else I've seen looks mostly cosmetic.


Simo Sorce
Samba Team GPL Compliance Officer <simo at>
Principal Software Engineer at Red Hat, Inc. <simo at>

More information about the samba-technical mailing list