CMake for D2 ready for testers

[Russel Winder]

On Fri, 2010-10-08 at 21:41 +0200, Jens Mueller wrote:
> > > Do you recommend to learn & use CMake instead of using tools like
> > > Xfbuild (I'm interested for D project and, so far, was accustomed to
> > > Haskell's Cabal, so looking for similar experience.)
> > 
> > For C, C++, Fortran, and hence D, I personally find CMake awkward and
> > clumsy.
> 
> I also think CMake isn't that shiny. But you can get the job done once
> you're familiar with it. And it has been adopted by some big projects:
> Blender 3D, Boost, clang, KDE, LLVM, MiKTeX, MySQL (see
> http://en.wikipedia.org/wiki/Cmake#Applications_using_CMake).
> That should be put into consideration.

Well KDE was about to choose bksys (the immediate ancestor of Waf) until
some nasty politiking went on and all of a sudden they chose CMake.  I
don't know all the details, but I know enough to say that that decision
was not made based on a proper study.

SCons is used by Intel for most of their software products, especially
the parallel tools suite, also by id Games for all their products.
Simply listing users of a product is a "pissing contest" and not at all
helpful.  If you choose a tool that many others have chosen and are
happy with then fine, you get the comfort of not being on your own --
and that is a good thing.  However, an individuals or organizations
actual needs may mean that using something not chosen by the herd is far
more beneficial.

All these arguments happen when choosing version control systems as well
as build systems.

> I never used this but CMake has generators for Visual Studio and through
> the Makefile Generators you can integrate it in CodeBlocks and Eclipse.
> Don't know how important this is. I live happily with the generated
> Makefiles.

SCons can likewise generate Visual Studio project files.  SCons can be
used directly in Eclipse so no need for Makefile generation.

> Coming back to the original question. I can recommend CMake especially
> if one plans to do C and C++ programming. For D we (Steve, Dean and I)
> are trying to improve the support. Fixing Mac OSX is next on my list.

I have no doubt that CMake is a viable alternative for some
people/organizations in some contexts.  As a replacement for Autotools,
then compared to Waf it comes third for me behind second place SCons.

> > I generally prefer SCons or Waf -- Waf is originally a fork of
> > SCons but now is its own thing, and is aimed at being an Autotools
> > replacement ("get source download and build on this machine" type
> > model).  SCons is better at handling the sort of situation I have:
> > source repository shared by many platforms all needing builds in situ.
> > Waf is somewhat faster than SCons.  For my sins I am peripherally
> > involved in the SCons development community, and I at some time elected
> > myself as the maintainer of the D plugin -- the plugin as D shipped
> > until recently with SCons assumed D 1.0 and I am only using D 2.0.  So
> > when I asked who could fix the problem, the answer came back "you can",
> > so I did, sort of :-) It would be good if there was a community of
> > D/SCons users so as to get some headway on making the SCons D plugin as
> > good as it needs to be.
> 
> I have to admit I neither know Scons nor Waf. Maybe these are superior.
> They're Python-based, right? I'll guess that makes them favorable for
> Python programmers.

SCons and Waf are both Python systems that have an internal DSL for
describing the build.  Both have the classic two phase operation:  read
the files and build the DAG describing the project and build; analyse
the filestore and spawn tasks in order to reconcile the actual filestore
with the required filestore. (Actually 'filestore' is a variable here,
you an target things other than the filestore, but its usually the
filestore being processed.)

Using Python (or any other dynamic language I would suspect, cf Rake,
Rant using Ruby) is a big win, certainly over m4 macros.  CMake has its
own language which is part way to being Lisp but has lots of quirks and
idiosyncrasies such that if they had just used a Lisp interpreter,
things would be a lot better.

> On top of my head some things I find nice in CMake. Just curious whether
> Scons/Waf have similar features.
> * Find Google Test/other libraries (if supported) in one line:
>   find_package(GTest REQUIRED)

Waf and SCons can both do this but it is not packaged as a one liner in
this form.  The issue is how the dependencies are packaged up in order
to create.  CMake has one route, Waf one route and SCons a slightly
different route.  CMake looks good on this point but Waf and SCons are
not poor in comparison.

> * Tight integration for testing and packaging (ctest, cpack)

Somewhat unfair to appear to name CTest and CPack as requirements as
they are are Kitware products integrated into CMake ;-)  Waf and SCons
both have infrastructure for supporting tests, they are just called
something different than CTest and CPack

> * Publishing build/test results

Isn't that the job of the continuous integration server?

> * No dependencies besides a C++ compiler for installation.

CMake requires cmake, make, bash, etc. in addition to the compilation
tool chain which is usually more than just the compiler.

Waf and SCons both require a Python installation, but that is
increasingly standard now.  No need for Bash or Make, but you do need
exactly the same toolchain otherwise.

> * Continuous Integration watching subversion repository

Why Subversion explicitly, it is so last century :-)  Bazaar, Mercurial
and Git are the "go to" version control systems these days.  Even if you
have a Subversion central repository, you use Bazaar, Mercurial or Git
as your client.  Well I do anyway!

Actually I am not sure what you mean by this.  CI is usually these days
either Buildbot or Hudson

> * Valgrind/Purify integration

I believe both have this but I don't know, in my C++ programming I never
use these tools.

-- 
Russel.
=============================================================================
Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder at ekiga.net
41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel at russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20101009/196ddbdc/attachment.pgp>