[Aptitude-devel] Towards a better build system

[Daniel Burrows]

On Thu, Apr 22, 2010 at 09:25:17PM +0200, Jens Seidel <jensseidel at users.sf.net> was heard to say:
> On Thu, Apr 22, 2010 at 07:56:12AM -0700, Daniel Burrows wrote:
> >   4) "make distcheck" fails because it tries to remove something in
> >      "/var".  (unless, perhaps, you're root.  I don't want to know what
> >      it does then)
> 
> Probably your fault :-)) You never liked this target and it often failed in
> the past.

  Well, part of the problem is that this behavior is hardcoded somewhere
inside automake.  I think the only way to avoid this is to not try to
install the state directory.

> >   6) autoconf/automake don't provide support for canned build options.
> >      Most aptitude builds use one of two sets of compile flags, but this
> >      isn't known to the build system, so I have to tell new contributors
> >      to enter "CXXFLAGS=-g\ -O0\ -fno-inline ./configure" before
> >      building if they want to debug.
> 
> You can easily add a --with-debug or --with-release option. This is trivial!

  I put it near the end of the list for a reason :)

> >   6) If I want to switch between configurations, I have to "make clean"
> >      and reconfigure, then recompile.  This means I lose all my build
> >      output whenever I switch back and forth;
> 
> Heh? Everyone uses build directories such as debug/ and release/ in which
> they started ../configure with different options. Both are independant of
> each other.

  Also near the end of the list for a reason.  Better variant support
is something I want in a new system, but not a reason to drop automake.

> >   Now, all the above *could* be solved in an automake-based system.
> > However, by my estimate the amount of work involved is on the same scale
> > as the work required to switch to another build system -- except that
> > if I switch to one that's more inherently flexible, the amount of work
> > *next time* I run into problems with the build system will be greatly
> > decreased.
> 
> How about maintaining two systems? So there should always a working one :-)

  I'll probably do that in the short term.

> >   So, somewhat arbitrarily, I've decided to start experimenting with a
> > collection of SCons build rules for aptitude.  SCons has some nice
> > features:
> 
> Isn't Cmake more used? (I don't know both.)

  I have no idea.  The one thing I do know about CMake is that it uses
a private build language (like Make and BJam), which is one of the main
things that frustrates me about autotools.

> >   1) Its build scripts are written in a general-purpose programming
> >      language that's widely known and supported (Python).  This
> >      eliminates several of my problems above immediately; for instance,
> >      Python has very well-developed facilities for modularization,
> >      encapsulation, and abstraction.
> 
> But it is probably harder to get support for e.g. Boost detection. boost.m4
> is very well maintained and works great (but initially writing it is hard).

  It's true that this is a concern, and it's the main reason I didn't
move away from autotools years ago.

  But a large part of why writing it is hard is the ".m4".  All most
autoconf scripts really *do* is walk over a list of configurations, try
some test with each one, and save the one where it works.  What makes
them deep black magic is that you have to write them in
m4-on-top-of-shell.

  That said: there are SCons recipies for things like Boost and gettext.
I haven't incorporated them yet because I'm mostly working without net
access, but I don't think they'll be hard to grab.  In the worst case,
we could always have an SConscript.in.

  Also, I'm a little less concerned about missing a few configure cases
with SCons because *the configure tests are written in Python*, which
means that any halfway competent programmer should be able to add their
own tests (if nothing else, by copying-and-pasting the existing ones).

> >   If you're curious, check out the Mercurial repository, where I have
> > a bunch of poorly factored and broken SCons stuff checked into the
> > tree.  It won't show up in distributed tarballs since I haven't
> > registered it with automake yet.
> 
> Why don't you add it to the autotools EXTRA_DIST variables so that it is
> also shipped with tar balls? It should not harm ...

  That's the eventual plan.  When I cut the last release, the SCons
build files were still in pretty bad shape, to the point that they
weren't even interesting as samples.  By the next release I expect
that the distribution will contain SCons files that can do a full
aptitude build.

  By the way, I wrote about 15 patches before and after work today,
and the current status is now that it can build aptitude with just
"scons".  Variants are partly in but broken.  Nothing else builds yet.

  Daniel

  Daniel