waf: building tely+texi, no pictures
The current state of waf is that we can't copy or link filenames that
go to the same directory (modulo srcdir/blddir). Yes, "cp ${SRC}
${TGT}"... where SRC is in the srcdir, and TGT is in the blddir...
fails. If you want to see the error, check out dev/gperciva, edit
Documentation/wscript_build, and uncomment the pictures subdir bit.
There's a message on the waf list about this problem, from July 2008.
There's a note that it's a known limitation that fixing it is on the
TODO list.
http://groups.google.co.uk/group/waf-users/browse_thread/thread/e4470c6d5268cb6a/7880b48830b72527?lnk=gst&q=copy#7880b48830b72527
(I'm not blaming other projects for not resolving issues, but it
*does* still cast serious doubts as to whether we want waf)
On the plus side, at least the two -init.pl files are almost merged in
this branch. I'll look at bringing that work into master in the near
future.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: waf building
On Tue, Nov 10, 2009 at 12:27:51PM +0100, John Mandereau wrote: > Le samedi 07 novembre 2009 à 19:26 +, 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@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: waf building
Le samedi 07 novembre 2009 à 19:26 +, 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 signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: waf building
Le mardi 10 novembre 2009 à 00:36 +, 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 signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: waf building
On Tue, Nov 10, 2009 at 01:04:11AM +0100, John Mandereau wrote: > Le samedi 07 novembre 2009 à 19:26 +, 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@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
Re: waf building
Le samedi 07 novembre 2009 à 19:26 +, 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 signature.asc Description: Ceci est une partie de message numériquement signée ___ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
waf building
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@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
