[Mono-devel-list] ANNOUNCE: mono build tool demo

[Paolo Molaro]

On 01/05/04 Miguel de Icaza wrote:
>    I have to say that I have been very disappointed with existing build
> system solutions.  Nothing really was an improvement over
> automake/autoconf, nor was completely designed to solve some of the
> problems that automake/autoconf solved.

The mbuild document and the look of the Buildfile is nice (though
there are some rough edges like the "inside" keyword, or the verbose
EXTRA_DIST handling). But since everyone seems over-excited, I'll play
the devil's advocate.

The autotools cover a very large range of issues:
aclocal: config and feature code snippets
autoconf: feature detection and configuration
automake: makefile simplification
make: build tool
libtool: library and link tool

For historical reasons it's quite a mess: many different tools,
many different implementation languages, ugly syntax and so on.
But it's also something that works fairly well, it's portable
(well on windows it's so slow to be unusable, but that is really the
fault of the windows OS) and has many advanced features.
There is also an additional issue: the tools work best when they are all
used together, so any replacement must solve the same set of issues to
be useful.

As it is explained in the mbuild docs, mbuild has a (nice) design to
solve some of the same issues that make and automake solve. There is
nothing in the docs that suggest it has a design to replace autoconf,
for example, or libtool (and, if it has, is the solution better then
what we have now?).
Portability-wise, mbuild seems to be a step back that people would be
willing to pay if it solved the other issues in a better way.
Some of the solved issues are:
* nice syntax (no whitespace significance and not overly verbose as the
xml-based tools)
* make dist/clean

But at this point the lacking features over make/automake are too many
to list, so we need time for the tool to mature (simply because it takes
a lot of time to implement the advanced stuff: -j support, revision
controlled dependencies, etc.).
There is one feature, though, that should be considered from the start
and this is the one feature where all the make replacements failed
in some way or the other: expansibility of the rules implementation.
make just executes the command with a shell, so people that write
makefiles have a fairly rich programming environment (well, as unix
shells go, I'll ignore the poor windows users).
Some build tools provide a limited set of builtin actions that can be
somehow combined with some verbose syntax. Others expose the language
they were implemented in (typically perl, python or scheme), because
they were create more for language evangelization than as a build tool.
Others expose yet another limited and otherwise usless custom
programming language. Some others require to write complex modules
that will be loaded at runtime by the build tool (or, worse, at
build-tool compile time!).
The rules in mini/Makefile.am are an example of rules that many build
tools would require me to walk on my head for what automake/make
requires just one simple line of code.

None of the make replacements, imho, succeded in creating the right
balance between syntax clarity, expansibility and easy of use that would
make them a compelling replacement for make. They failed because this is
a really hard issue to address, so I'm not blaming anyone, but I'm also
not expecting mbuild to have a solution for it that satisfies the 95% of
developers that still use the autotools and make. Of course, I'd love to
be proved wrong.

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better