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

[Paolo Molaro]

On 01/06/04 Peter Williams wrote:
> 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)"
> ]

Ok, it's nice that simple things are handled in a simple way.
Now, what about something more complex? How do you get the build tool to
add a define if a feature is enabled? This doesn't seem to map too well
to a virtual dependency. What if I want a feature enabled if two config
checks succeed and another one fails?
And how would you represent the bundle support in the mono configure.in
(with the correspoonding Makefile.am snippets)?

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

Well, I'm the first to hope mono will be ported to a dozen architectures
(and most of the portability issues are solved, with the x86, ppc and
itanium ports), but still, each port requires some effort and
maintainance... so you'd limit the potential users of your tool
somewhat.

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

That level of extensibility also makes automatic dependency tracking
more difficult, since user code could add dependencies that are hidden
to the build tool.

> 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

I think either a lisp syntax or a 'small' language are not going to cut it.
Maybe someone should have a look at how much work it is to port a simple
bourne shell like ash to C# (with the useful utilities built in a la
busybox): it might make for another language that runs on mono even if
it's not used in mbuild;-)

Thanks.
lupus

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