lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Please review: Brain surgery on the build system, first stage


From: John Mandereau
Subject: Re: Please review: Brain surgery on the build system, first stage
Date: Mon, 06 Aug 2012 13:12:19 +0200

[adding on -devel]
Le lundi 06 août 2012 à 12:12 +0200, John Mandereau a écrit :
> I guess the state where you brought StepMake made it a potential
> competitor to Automake (but not Autoconf); I have never used Automake,
> but after having read a bit about it (comments on the web, wikipedia,
> its manual), the result you achieved, avoiding adding an extra layer on
> top of m4/make/shell, is quite appreciable.

That said, there is a design I don't like, which BTW is not specific at
all to StepMake: tying build order and make recursion with directory
layout causes trouble in rules with prerequisites that are built in
other directories. IMHO it would be much better to use make recursion
for building stages (all, test, doc-1, doc-2...) instead of directories,
with a toplevel GNUmakefile including submakefiles from subdirectories.
I don't think it would be very easy to do this with GNU Make, as it has
little support for variables scoping and figuring out a global build by
grabbing makefiles in subdirectories, with all the playing with paths
that would be needed; maybe this could be hacked by enclosing rules in
macros with directory prefix as a parameter, then call them  with eval;
or, if this appears to be too hackish, we could keep the per-directory
build system layout for GNU Make, and try such a tree-global build
layout with a build tool designed for this, namely Omake:
http://omake.metaprl.org/index.html
I discovered it as I've looked into using OCaml for applications of my
PhD work.  If/when I have time, I'm eager to try it for building
LilyPond docs in a portable way, the main issue is reproducing enough
configure stuff within Omake for detecting required/optional programs
and versions.


> > Yes, I agree and support you in this.  Although generic/specific has
> > some nice academic feel; this separation truly is a burden and has been
> > for a while.  This opens the door to further simplifications and
> > improvements, if someone feels like it.
> 
> That's right.  The simplification of the current build system also opens
> the door for writing another one more easily.
> 
> Best,
> John





reply via email to

[Prev in Thread] Current Thread [Next in Thread]