[Top][All Lists]

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

Re: Documentation/essay/

From: John Mandereau
Subject: Re: Documentation/essay/
Date: Thu, 9 Jul 2009 10:11:13 +0200

2009/7/9 Graham Percival <address@hidden>:> On Thu, Jul 09, 2009 at 08:35:15AM +0200, John Mandereau wrote:
> Well, the website is current built with:
>  texi2html -I=$(imagedir) -I=$(exampledir) --output=$(outdir) \
>  --init-file=web-texi2html.init --split=section lilypond-general.texi
> so doing this with SCons would be a trivial change.  :)

You know that after adding the inkscape anf format-page stuff to this,
then the translations, it will be suddenly a bit less trivial :-)

> I admire you for doing the makefiles in the past; I've always been
> too scared to touch that stuff myself.  But comparing the
> website's makefile to the lilypond doc makefiles, I really wonder
> where all that complexity comes from.

Complexity comes from
- many compilation steps (lilypond-book, Texinfo processors, text substituion with Python scripts)
- dependencies across directories (that we haven't managed to handle completely with make yet(*),
and which I don't plan to contribute to achieve completely using GNU make)
- output in subdirectories (provided by stepmake system)
- support for building outside the source tree (stepmake)
- avoiding make code duplication with variables and pattern rules on one hand, and template
files (stepmake) OTOH
- limited programming features of GNU make (only text manipulation and macros)
- specific needs regarding concurrency (no several simultaneous lilypond-book instances)

(*) e.g. translated docs building implicitly assumes that documentation in English has been built first.

> What do you think about trying SCons to build the docs
> (Documentation/*), as a possible "first try" before a possible
> switch for other parts of LilyPond?

As it will similar to the website, it is a sensible idea.

> It's under the MIT license,
> so I can't see any possible reason for GNU to complain.

The reason to complain is that we would favor a non-GNU package
that has a GNU equivalent; however, let me record technical arguments
below, so we will only have to link to this message in the archives when
we have to give reasons for switching to Scons.

Scons brings power of a full programming language (Python), whereas
GNU make only provides text manipulation (macros and text processing
functions), which makes some bits difficult to read, as you can admire with
the following quote from make/ly-rules.make.

# This allows -j make option while making sure only one lilypond-book instance
# is running at the same time

$(eval $(firstword $(MASTER_TEXI_FILES)): $(foreach i, $(wordlist 2, $(words $(MASTER_TEXI_FILES)), $(MASTER_TEXI_FILES)),$(CHAIN_RULE)))

Well, the previous example is quite simple in the respect that is is pure make;
some goals can only be achieved with hairy mixing of shell and make, unless
you use external scripts, which is what we ended up going with Python


reply via email to

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