waf building

[Graham Percival-3]

I've got waf buliding contributor .html and .pdf  in the dev/gperciva
branch.  I was pleasantly surprised to discover that waf supported a
--targets=  command-line, so we can specific an individual manual to
build.  I'm less happy that this appears to ignore the "after=foo"
check, so none of the dependencies are checked.  At the moment, I
remain unconvinced that waf is actually any good.

Actually, I suppose we could add a custom command-line option for
building specific manuals (*with* their dependencies), so I guess this
isn't such a big deal.

Bottom line: if we actually want waf, it can be done within two weeks.


At least, the non-translated stuff can be done within two weeks.  I'm
*not* going to screw around with the translations.  I know I said the
same about waf, but I got so pissed off about all the fluffing around
that I'll take it over.  But I seriously don't mind making releases
without any translations whatsoever, so if anybody *does* want
translations, they'd better be willing to work on the build system
once the main english docs are working in waf.

*if* we want waf.  As I said, I remain unconvinced.

- Graham


_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[John Mandereau-2]

Le samedi 07 novembre 2009 à 19:26 +0000, Graham Percival a écrit :
> I've got waf buliding contributor .html and .pdf  in the dev/gperciva
> branch.

Ah, you got upset enough by the old build system too :-)


> I was pleasantly surprised to discover that waf supported a
> --targets=  command-line, so we can specific an individual manual to
> build.

I'm not sure specifying an individual manual to build should be done in
a target; in an ideal docs building system, it should be easy to choose
independently the output format, the manuals that are compiled, and the
offline/online output targets.  Maybe "doc" would remain the target
name, and other parameters could be set as other command-line options as
you suggest, or in environment variables (probably not useful in this
case).


>   I'm less happy that this appears to ignore the "after=foo"
> check, so none of the dependencies are checked.

Shouldn't the dependencies which are source files wrt the task be
included in 'source' rather than 'after'?  I'll try to work it out.
Maybe 'after' should contains tasks rather than nodes (sources files)
anyway, but this is not a firm claim.


> Actually, I suppose we could add a custom command-line option for
> building specific manuals (*with* their dependencies), so I guess this
> isn't such a big deal.

Sure.


> Bottom line: if we actually want waf, it can be done within two weeks.
>
> At least, the non-translated stuff can be done within two weeks.  I'm
> *not* going to screw around with the translations.

If the build system for docs in English is well designed enough, it will
be little work to make it work for translations.  I must deal with
translations before the next stable release, otherwise my translations
coordinator job will no longer make any sense :-P
Anyway, as somebody, i.e. you, finally got his hands dirty with waf, I'm
motivated again to work on it.


> *if* we want waf.  As I said, I remain unconvinced.

I'm willing to support alternatives to our build system and SCons other
than waf, if you can show me one.  Waf is certainly not a very mature
build system, but I think it has solid enough bare bones to try it.

Best,
John


_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[Graham Percival-3]

On Tue, Nov 10, 2009 at 01:04:11AM +0100, John Mandereau wrote:

> Le samedi 07 novembre 2009 à 19:26 +0000, Graham Percival a écrit :
> > I was pleasantly surprised to discover that waf supported a
> > --targets=  command-line, so we can specific an individual manual to
> > build.
>
> I'm not sure specifying an individual manual to build should be done in
> a target; in an ideal docs building system, it should be easy to choose
> independently the output format, the manuals that are compiled, and the
> offline/online output targets.  Maybe "doc" would remain the target
> name, and other parameters could be set as other command-line options as
> you suggest, or in environment variables (probably not useful in this
> case).

If I'm working on the LM, then I *don't* want other stuff be
built.  That goes especially for the CG and
general/web/whatever-the-word-of-the-week-is, since they don't
require lilypond-book.

Yes, ideally the build system will only do the manuals that have
been touched... but what about starting from a blank git checkout?
It would suck to spend 2 hours building all the docs when you just
want to check that a typo correction in the French translation of
the website looks good.

Also, it might make the parallel building easier.

Put it another way: why *not* have them as separate tasks?

> > At least, the non-translated stuff can be done within two weeks.  I'm
> > *not* going to screw around with the translations.
>
> If the build system for docs in English is well designed enough, it will
> be little work to make it work for translations.

It will be designed enough.  It will be designed so much that,
when it is done, you will look at it and say "wow, that is
designed".

> > *if* we want waf.  As I said, I remain unconvinced.
>
> I'm willing to support alternatives to our build system and SCons other
> than waf, if you can show me one.  Waf is certainly not a very mature
> build system, but I think it has solid enough bare bones to try it.

I'm mostly just pissed about the "blddir" stupidness.  It's not
the 1970s, folks!  Adding the "ui" won't cause the source file to
be too large for the punch card!  Besides, one of python's claims
to fame is that it's more readable than most other languages.  Why
the bloody mao would they throw that away to have stupid variable
names like "blddir" ?!?!


Ok, I'll go ahead with this.  My mood will suffer, and therefore
anybody on the lists with a thin skin will _also_ suffer, but at
the end of two weeks we'll have a doc build system that will make
people say "wow, that is designed".

- Graham


_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[John Mandereau-2]

Le mardi 10 novembre 2009 à 00:36 +0000, Graham Percival a écrit :
> I'm mostly just pissed about the "blddir" stupidness.  It's not
> the 1970s, folks!  Adding the "ui" won't cause the source file to
> be too large for the punch card!  Besides, one of python's claims
> to fame is that it's more readable than most other languages.  Why
> the bloody mao would they throw that away to have stupid variable
> names like "blddir" ?!?!

You're right.


> Ok, I'll go ahead with this.  My mood will suffer, and therefore
> anybody on the lists with a thin skin will _also_ suffer,

I've already (silently) suffered from this.

John


_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[John Mandereau-2]

Le samedi 07 novembre 2009 à 19:26 +0000, Graham Percival a écrit :
> I've got waf buliding contributor .html and .pdf  in the dev/gperciva
> branch.  I was pleasantly surprised to discover that waf supported a
> --targets=  command-line, so we can specific an individual manual to
> build.  I'm less happy that this appears to ignore the "after=foo"
> check, so none of the dependencies are checked.

Please ignore my other reply on this technical point, which is
inaccurate.  IIUC, dependencies should not be specified with 'after'
parameter, but a scanner that can be easily written reusing the one for
TeX should find dependencies, then Waf should find either the
dependencies as source files or output files produced by other tasks.

I'm sorry again not for being more active, but adminstrative stuff for
my PhD is burning my a** (direct translation from French).

Best,
John


_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[Graham Percival-3]

On Tue, Nov 10, 2009 at 12:27:51PM +0100, John Mandereau wrote:

> Le samedi 07 novembre 2009 à 19:26 +0000, Graham Percival a écrit :
> > I've got waf buliding contributor .html and .pdf  in the dev/gperciva
> > branch.  I was pleasantly surprised to discover that waf supported a
> > --targets=  command-line, so we can specific an individual manual to
> > build.  I'm less happy that this appears to ignore the "after=foo"
> > check, so none of the dependencies are checked.
>
> Please ignore my other reply on this technical point, which is
> inaccurate.  IIUC, dependencies should not be specified with 'after'
> parameter, but a scanner that can be easily written reusing the one for
> TeX should find dependencies, then Waf should find either the
> dependencies as source files or output files produced by other tasks.

waf book, chapter 5, Task execution order.  Ways to control the
order of tasks:
- task groups
- precedence constraints (before= after=)
- file extension production (ext_in= ext_out=)
- task1.set_run_after(task2)

In the next page, it appears that "dependencies" in waf-language
are source files required for the task.


Yes, we might want to do some kind of scanner for dependencies,
but to say "run this rule before that rule" -- such as "generate
version.itexi, by running the rule cunning named version.itexi" --
I think the easiest thing is to use "after" or having a task
group.

(actually, I must admit that task groups are looking appealing)

- Graham


_______________________________________________
lilypond-devel mailing list
lilypond-devel@...
http://lists.gnu.org/mailman/listinfo/lilypond-devel