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

[Peter Williams]

Hi Paolo,

On Tue, 2004-01-06 at 12:22, Paolo Molaro wrote:
> 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.

No problem :-)

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

There is a design. The rough idea is that certain targets are in a
'Configuration' group, and the tool has a mode that lets you view and
modify all of their values. Examples would be /config/want_foofeature or
/config/cc_program. Ideally, the developer could add annotations useful
to the end user:

want_foofeature = UserConfigurableBool [
	default = true
	truedesc = "Use the Foobulator (recommended)"
	falsedesc = "Don't use the Foobulator (reduces executable size)"
]

Then the build tool could even generate a .po file from all the build
files and you could have translatable build configury ...

Similarly, there would be a 'Prerequisite' group, and the build tool
would shout at you if the targets in that group failed to build. With a
decent suite of operations (along the lines of AC_TRY_COMPILE,
AC_CHECK_LIB, etc) I think this setup would provide a good framework for
replacing autoconf checks, and the integration with the build tool would
be a big win.

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

Portability is of course an issue. The way I figure it, it won't be
insanely difficult to get it as portable as Mono... and not relying on
the shell might make some other portability issues a lot easier to deal
with. Beyond that, I don't think anyone imagines that MBuild will be
running on Vax machines any time soon.

As you said, we definitely need time for things to mature. I certainly
don't want to replace the MCS or Mono build systems. I just wanted to
put the basic ideas out there.

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

I am totally aware of this. I'm not sure how to approach this problem.
Initially, I wrote a small Lisp interpreter and tried to express all the
build rules through it; it's a cute idea, since build rules are more or
less functional, but the syntax would scare a lot of people and I want
to be able to compile rules into assemblies ... writing a Lisp -> IL
compiler is not my idea of a good way to get things moving :-)

However, once the infrastructure is in place, I think I might take
another look at the Lisp foundation. If I can figure out a good way to
bind to preexisting rules, I think it could make a workable solution. I
know that there will be at least two major subsystems: something for
executing external programs, and another for processing text files a la
grep, sed, cat, etc. With the right hooks, I think the majority of
custom build rules could be implemented fairly easily.

The other ideas that I can see are either inventing a small procedural
scripting language or using some kind of CodeBehind system. Once I write
enough build rules, the infrastructure might be stable enough for the
latter system to make sense. On the other hand, I've always felt that
CodeBehind is sort of a lame idea. On the third hand, I've never used
it, and the current build rules do involve a reasonable amount of
boilerplate code, so it might make sense.

Peter

-- 
Peter Williams                          peter at newton.cx

"[Ninjas] are cool; and by cool, I mean totally sweet."
                              -- REAL Ultimate Power