[Aptitude-devel] Towards a better build system
jensseidel at users.sf.net
Thu Apr 22 19:25:17 UTC 2010
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
> 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
> 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
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
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 ...
More information about the Aptitude-devel