[Aptitude-devel] Towards a better build system

[Jens Seidel]

Hi Daniel,

On Thu, Apr 22, 2010 at 07:56:12AM -0700, Daniel Burrows wrote:
>   aptitude currently uses autoconf/automake as the basis of its build
> system, with various extra stuff hacked on as needed for
> internationalization, documentation, etc.  This is nice since it follows
> the de facto free software standards automatically.  It's not so nice in
> a few other ways:
 
>   2) The whole make/automake/autoconf/m4 toolset doesn't offer very good
>      facilities for abstraction.  You can see this, for instance, in the
>      pile of copy-and-paste in doc/, where each language seems to copy
>      another language's Makefile and hack it up.  We should be able to
>      just say "build the docs for XX".

That's the mess from whoever wrote it. It's possible to improve this.
 
>   3) Because the autotools are built in languages that don't lend
>      themselves to open-ended programming and have a lot of weird quirks
>      (sh, m4, make), writing simple "configure" tests tends to be a major
>      task, to the point that I avoid it if at all possible.

Right. I know autotools well but m4 not at all.
 
>   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.
 
>   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!
 
>   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.

>   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 :-)
 
>   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.)
 
>   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).
 
>   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 ...

Jens