The Software Construction Methodology that Never Was
- I have worked a great deal with Make, Autoconf, Automake, Libtool, RPMs,
Source RPMs and RPM Specs. I cannot say I absolutely detest it. It can
sometimes be a nice change from writing code. On my Mandrake system, I
routinely compile Source RPMs, after I realized that installing the
RPMs from Mandrake Cooker (Mandrake's Bleeding Edge Distro) would require
me to satisfy too many dependencies, and I don't want to upgrade half of
my system pre-maturely (albeit I sometimes evidently do that )
Still, I cannot say that this state of the art is by any means the ideal
way of doing things. For one thing, I wish there was a way I could
permanently configure a package the way I want it to, instead of having to
maintain my own modified RPM Spec. Also, it would be nice to be able to
incrementally compile a dependency of source packages. From what I
understood, Gentoo and the BSDs have resolved this, albeit sometimes they
are completely alienable to binaries.
Another thing that bothers me is that I have to maintain the RPM Spec (or
the Debian Package) vis-a-vis with the Automake files (or the Perl
package). I also am not too fond of autoconf, and wish I could bootstrap
the package with something better than a very crude Bourne shell script.
Another thing is that RPM Specs seem to vary from system to system (even
RedHat and Mandrake have separate versions), and I wish I could somehow
maintain one version of it. It might be possible with a little
Pre-processing magic, but so far I did not find the time or the will to
work on it.
There have been several efforts to resolve the various problems posed by
this state of the art:
1. The Software Carpentery Project - http://sc-archive.codesourcery.com/
This tried to create a top-down replacement for building packages,
configuring them (and testing them and keeping track of open issues, but
these are of lesser interest). They restricted the packages to be written
in or scriptable by Python.
They had some very nice ideas, but I'm not sure if they have a big chance
of converting the masses any time soon. For once, developers would be very
reluctant to dump their working configurations in favour of a new-fangled
tool that is incompatible with the previous one. And even more
importantly, they won't be able to convert back, if they do.
For a few critiques of the standard way of doing things.
2. Cook - http://gd.tuwien.ac.at/softeng/Aegis/cook/
An alternative to Make written by Peter Miller (of Aegis fame). There's a
review of it here:
It is possible to convert makefiles to cookfiles but not back.
3. OpenPKG - http://lwn.net/Articles/8289/
OpenPKG is a cross-platform packaging utility that can be used to create
native packages for a variety of UNIX platforms.
4. GNU Make - a make on steroids with many features. (which Automake does
not depend on, though)
5. Ant - a Java and XML tool for constructing packages.
6. Cons - a Perl-based Make Replacement.
And there may be others that I missed.
This topic interests me so much that I consider making it my masters
thesis, should I decide to do an M.Sc. (which is not going to be anytime
soon, as I'm tired of studying).
 - http://www.advogato.org/person/shlomif/diary.html?start=77
 - http://www.joelonsoftware.com/articles/fog0000000052.html
Shlomi Fish shlomif@...
Home Page: http://t2.technion.ac.il/~shlomif/
Home E-mail: shlomif@...
"Let's suppose you have a table with 2^n cups..."
"Wait a second - is n a natural number?"