Re: dist failures

[Graham Percival]

Han-Wen Nienhuys wrote:
> I've just tried to package lilypond for release, and I am encountering 
> several 'make dist' errors.  I would appreciate it if you would verify 
> that "make dist" still works every once in a while.

Does "make dist" require the ability to run "make"?   I've been running 
"make web" via the downloaded binaries for the past year and a half.  If 
I can do "./configure; make; make install" on Debian/Etch without 
installing any special patches to ghostscript or whatever, I'll start 
doing things that way.

I regularly check things with "make web", although apparently not after 
I made my final changes last time.

> Secondly,   "make dist" now barfs with 
>
> /usr/bin/python ../../scripts/lilypond-book.py -I ./ -I ./out -I ../../input -I 
> ../../input/regression/ -I  [..]
> /home/lilydev/vc/lilypond/input/manual -dcheck-internal-types -ddump-signatures 
> -danti-alias-factor=2" --verbose NEWS.tely
> lilypond-book.py (GNU LilyPond) @TOPLEVEL_VERSION@
> Reading NEWS.tely...
> Dissecting...
> lilypond-book.py: error: file not found: makam.ly

Sorry, I forgot to add that file (it was an "untracked file" in my 
source tree).

makam.ly was also recently deleted from input/test/ ; if you have an old 
collated-files.texi, it might be trying to find that deleted file.

> I think I've remarked it before, but I forgot the reasoning.  Can you explain
> me another time why don't label test files like
>
>
> \header {
>   snippetLabels = "new/pitch,microtonal,ethnic" 
> }
>   
> ?
>
> With this approach 
>
>  - files/directories don't have to be renamed all the time
>
>  - a snippet can have multiple labels
>
>  - we can do away with all the separate GNUmakefiles.
>
> I think this would simplify administration of all the files.

All valid points except for the last one -- the administration of these 
files is done in LSR.


As for the reasons we're doing it this way:

1)  This is the easiest / most elegant way I could think of doing it.  I 
don't understand the lilypond make system at all, and I didn't want to 
ask anybody else to rewrite the build system.

2)  It's fairly easy to understand how the current system works: you 
have a directory structure from the lsr-snippets.tar.gz, and a directory 
structure from input/new/.  Those get combined to form input/lsr/, which 
is the thing that users actually see.

3)  LSR currently doesn't support multiple labels, so adding it in the 
source tree won't be much use.  This probably could be added, but IMO 
we've long since surpassed the "user interest vs. developer time" 
boundary, so I'm reluctant to bother Sebastiano about this.


Cheers,
- Graham