On Wed, Dec 09, 2009 at 11:11:20AM +0100, John Mandereau wrote:
> Le mercredi 09 décembre 2009 à 01:19 +0000, Graham Percival a écrit :
> > Only if you accept responsibility for making it work in makeinfo,
> > texi2pdf, and texi2html. This duplicates 10 or 20 commands in
> > macros.itexi. That's one file. When you change a manual name,
> > you need to update 4 lines of texinfo.
>
> 4 lines of Texinfo multiplied by the number of languages, which
> completely changes the deal.
It's still only a few minutes.
> > IMO, the "time saved" vs. "time spent"... including debugging any
> > fancy macro games in all the doc-building programs, including
> > debugging any problems that people with other versions of those
> > tools have... is totally not worth it.
>
> All this is wrong:
> - this change wouldn't involve the build system at all;
If the change is done badly, then the docs stop building.
> - we don't have to support different versions: texinfo.tex is included
> in sources (and TeX is stable enough so it doesn't matter), we already
> require a specific version of Texi2HTML, and makeinfo syntax support is
> stable enough;
It would be nice if we *didn't* have to require a specific
versioin of texi2html.
> > - we'd lose internal consistency if we ever wanted to change the
> > section name
>
> I don't understand this point.
We'd have to tell writers "use @lilysection{foo} to start a new
section, unless you want to have a different title instead of the
node name, in which case do @node{foo} @section{foo}".
> > Duplicating the node/section name is a basic feature of texinfo.
> > It's not a big deal.
>
> It makes translation a bit more tedious, though.
I'll take "tedious" over "clever half-baked almost-working" any
day.
Look, lilypond does *not* have a good record of "clever,
time-saving" build stuff. Yesterday I had to spent 15 minutes
figuring out how to add ja to the tarball for 2.12.3, because
somebody thought it would be cute to get the language list from
python/something.py, and they'd commented out the "ja" from line
123 in that file.
Take Trevor -- by any stretch of the imagination, he's an ideal
contributor/developer. Can he build the docs? No. Ok, maybe
this is a one-off error... but could he identify the problem? No.
Having asked us about the problem, could well tell me? Not as far
as I know; the only way to debug build errors is to skim through
literally hundreds of lines of warnings and errors, and look for
some unfamiliar warnings+errors. That is *incredibly* frustrating
for people who want to help out.
You're about to say "yeah, but this is a really simple thing that
has nothing to do with the doc-building problems". I call BS.
It's yet one more complication. And again, we have a *terrible*
record of "oh, this will make things easier" garbage that doesn't
work. By your own admission, you're going to be busy working on
your phd soon. That means that *I'll* be left explaining things
to new contributors, trying to fix whatever build problems there
are, trying to make it work in texi2html 1.84 or 2.0 or whatever
number they give it when they intergrate it into texinfo... etc.
If the waf system was working... mao, if anybody was *working* on
the waf system... and it had a good logging system for the
doc-builds, good warnings, etc... then I'd consider it. If the
current build system was working, and had been working continually
for the past 3 months, I'd consider it. Oh, and what happened to
the plan of merging the init files? Has that also been abandoned?
With regards to the waf stuff: I'm still willing to write wscript
files for all the English docs. But I'm not willing to fix bugs
in waf. Somebody needs to fix those, or else pester the waf
authors into fixing them.
I don't think I can express how unhappy I am with the build
situation without going off into a huge curse-filled rant that
wouldn't do anybody any good. So let's just pretend I did that,
and know that I am /seriously/ pissed off at the stepmake system,
the python scripts, the translations, and everybody who worked on
this stuff in the past.
- Graham
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel
