CMake (was More about x-packages)

[pcpa at mandriva.com.br]

Quoting "Alan W. Irwin" <irwin at beluga.phys.uvic.ca>:

[ Sorry, for quoting everything bellow, but it may be helpful for some
people, as I find the information very valuable ]

  I have nothing agains't autotools, and maybe I had exagerated on
"few hours" as I measured it only 2 or 3 times, but I know it is around
2 hours to rebuild all modules/xserver/apps/etc (i.e. around 6 times
slower).
  I am not sure if people would want to switch to cmake at this point,
maybe have some optimized setup so that most scripts are run only once,
I believe someone was working on it (sorry for not even knowing all the
details before this reply). Or maybe, switch back to imake, what may be
considered a step backwards. And this is the kind of thing that will not
make some people happy, i.e. people working on different projects that
depend on the build system adopted by Xorg.

  Well, talking a bit more about "x packages", what I am considering
(still without stoping to "think hard" about it :-) to generate
dependencies, is a script that will evaluate the .deps/*.Po files, and
store gathered information in a "x packager devel" package. But this is
just about considering special cases like updating the X Server package
and knowing if modules need to be rebuilt, i.e. if a new functionality
is added only to the X Server, modules don't need to be repackaged;
this ofcourse assumes modules need headers to know about symbols, but
there are few things left that use some other method like "type punning",
using something like LoaderSymbol("some-string"), etc.
A possibly proper implementation would be to create some kind of type
sign for every symbol, but this would mean running a parser with the
same arguments as the compiler and that interprets them identically,
what probably would be impractical and/or require way too much work.

>>  :-) Well, I expect that people that generate binaries from sources will
>> care to install autotools, but I see the point of having the generated
>> files, as it may take significant time to regenerate them, due to the
>> extensive tests. For example, monolithic X Free86 would build everything
>> in less than 20 minutes on an average P4, while modular Xorg will take
>> a few hours, and most of the time is spent on autotools scripts.
>
> You will get some substantial speed improvements if you move to a different
> build system.  At least that is what KDE experienced when they moved from
> autotools to CMake, and that was the PLplot developer's experience as as
> well when we moved PLplot from autotools to CMake.  The configuration speed
> improvements are because cmake is a fast executable that takes the place of
> the relatively slow configure script.  There are also build speed
> improvements which I ascribe to the cmake executable setting up
> straightforward Makefile rules to do compiling and linking while autotools
> uses libtool, a ~220K (!) script that must be run for every compile or link
> step.
>
> Another advantage of CMake is it is quite easy to understand so that
> build-system support tends to be more widespread within a software project
> rather than relying on one or two gurus to actually understand autotools.
> That was a big deal for me because in the past I did spend a lot of time
> implementing autotools support for new PLplot features or attempting to
> debug autotools build problems for PLplot. I was tired of that effort.
>
> I am well aware that X changed to the autotools build system not that long
> in the past, and most X developers are probably not immediately ready for
> yet another such transition.  In fact, if the PLplot experience can be
> generalized there will be a tremendous amount of initial nay-saying with
> virtually all of it based on no experience with CMake! However, if just one
> forward-thinking X developer is concerned enough about the slow autotools
> configure and build speeds or the amount of autotools "magic" that is
> required to support new X features, then I suggest they try developing a
> CMake-based build system for just part of X (at first) to see how they like
> it for their own builds.  From such a start it is relatively easy to go the
> rest of the way to a full-blown CMake-based build system that everybody can
> use.
>
> CMake-based build systems can be developed in parallel with autotools
> because there are no filename name clashes between the two build systems.
> When we tried that approach for PLplot there was only one downside; our team
> of developers (despite the initial nay-saying) caught on so fast to using
> CMake that all our new features over the last year have only been
> implemented in our CMake-based build system. That was the death knell of our
> autotools-based build system, and we have just now completely removed it as
> a result.
>
> The PLplot developers have collected links at
> http://www.miscdebris.net/plplot_wiki/index.php?title=General_CMake_documentation_links
> which we have found useful during the development of our new CMake-based
> build system.
>
> Alan
> __________________________
> Alan W. Irwin
>
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (astrowww.phys.uvic.ca).
>
> Programming affiliations with the FreeEOS equation-of-state implementation
> for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
> package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
> Linux Links project (loll.sf.net); and the Linux Brochure Project
> (lbproject.sf.net).
> __________________________
>
> Linux-powered Science
> __________________________
>