Re: Please test gub

[Knut Petersen]

Hi everybody!
> > I think with the attached test-patch on top of the patch I already sent to you 
> > 'make lilypond' (not only bin/gub xxx::lilypond) should succeed after you put 
> > the newly created wrapper directory in front of PATH.
>
> I see; this wrapper directory is more convenient than asking the user to provide a 
> dir with only the symlinks python{,-config} -> /some/where/python2{,-config} on 
> his own and add it to the PATH.
>
> But isn't it against the purpose that now the shebangs of bin/gub/* read
>
> #! /usr/bin/env python2
>
> ? I think you meant: add the wrapper directory PATH such that we *don't* have 
> to replace python by python2 in those shebangs.
Yep, most if not all of those should be removed.  I changed those files at a 
time when I thought I would not need the wrappers.

> -TARGET_PYTHON=/usr/bin/python
> +TARGET_PYTHON=/usr/bin/env python
>
> in gub/specs/lilypond{,-doc}.py (rather than python2) is necessary and (almost) 
> correct in the patch, though.
No, here I meant what I wrote, currently '/usr/bin/env python2' instead of the 
original '/usr/bin/python' has to be used in lilypond.py and lilypond-doc.py

'/usr/bin/env python' should be the right solution, but it is not:

For more than 10 years gub/specs/lilypond.py used /usr/bin/python. That means that during lilypond-test the system's python interpreter is used as the interpreter for the musicxml2ly script, not our own python in target/tools.  At some currently unknown point in time musicxml2ly became incompatible 
to our python 2.4. The hidden usage of the system's python masked that incompatibility.

With our python 2.4 musicxml2ly does not barf, it simply produces garbage that 
lateron causes lilypond to fail.

@Werner: Didn't you write something about updating python in gub?

Knut