Le vendredi 12 décembre 2008 à 06:21 -0800, Graham Percival a écrit :
> On Fri, Dec 12, 2008 at 11:25:44AM +0100, Werner LEMBERG wrote:
> > Someone this list (Graham?) made the suggestion to move all script
> > subdirs into the `script' directory to avoid cluttering of
> > lilypond's top-level dire
On Fri, Dec 12, 2008 at 11:25:44AM +0100, Werner LEMBERG wrote:
>
> > I've started creating auxscripts/ (for scripts that needn't be built)
> > and auxpython/ (for Python modules that needn't be built), and I'll
> > commit as soon as I can't find remaining breakages.
>
> Someone this list (Graham
> OK, I buy your idea, but the involved changes are invasive and will
> also require changes in GUB. I'll do my best to keep everything
> working thanks to testing and greping through the sources, but I may
> miss some details -- you have been warned.
:-) A new build will show all the problems.
Le lundi 08 décembre 2008 à 07:58 +0100, Werner LEMBERG a écrit :
> > > Then I suggest a new directory `auxscripts'. It would simplify
> > > maintainance.
Simplifying maintenance is a good point: buildscripts has become a mess,
it contains a mix of scripts and Python modules, some of them are us
> > . Scripts which are run by the build process. These *must*
> > substitute the Python binary path.
> >
> > . Scripts which are run by the lilypond maintainers so that the
> > data in the git repository is in good shape. All such files
> > should be moved to a separate directory.
> >
> >
On Mon, Dec 08, 2008 at 07:58:52AM +0100, Werner LEMBERG wrote:
> There are two types of scripts:
>
> . Scripts which are run by the build process. These *must*
> substitute the Python binary path.
>
> . Scripts which are run by the lilypond maintainers so that the data
> in the git
> > Then I suggest a new directory `auxscripts'. It would simplify
> > maintainance.
>
> The only good reason for building most buildscripts is specifying a
> Python binary path at configure invocation different from the
> default Python binary when scripts are run, but this is might be a
> suffic
On 2008/12/04 16:59 +0100, Werner LEMBERG wrote:
> > Maybe it shouldn't be in buildscripts/, but I it definitely
> > doesn't belong in scripts/
>
> Then I suggest a new directory `auxscripts'. It would simplify
> maintainance.
The only good reason for building most buildscripts is specifying a
P
> I didn't realize that we "built" makelsr.py. It doesn't have any
> @...@ variables.
AFAIK, all files in `buildscripts' are `built'.
> > BTW, isn't it an error that `makelsr.py' starts with
> > #!/usr/bin/env python
> > instead of
> > [EMAIL PROTECTED]@
>
> Hmm. Maybe. But you *do* reali
On Thu, Dec 04, 2008 at 08:25:34AM +0100, Werner LEMBERG wrote:
>
> > > I notice Werner recently changed the permissions on a lot of
> > > files, including makelsr.py. Can somebody explain how I'm
>
> You shouldn't use the versions in `buildscript' at all. Instead, use
> the versions in `builds
> > I notice Werner recently changed the permissions on a lot of
> > files, including makelsr.py. Can somebody explain how I'm
> > supposed to run these files without using chmod to change the
> > permissions back temporarily?
You shouldn't use the versions in `buildscript' at all. Instead, use
On Thu, Dec 04, 2008 at 01:23:59AM +, Neil Puttock wrote:
> I notice Werner recently changed the permissions on a lot of files,
> including makelsr.py. Can somebody explain how I'm supposed to run
> these files without using chmod to change the permissions back
> temporarily?
Well, you could
Hi Neil,
On Thu, Dec 04, 2008 at 01:23:59AM +, Neil Puttock wrote:
>
> I notice Werner recently changed the permissions on a lot of files,
> including makelsr.py. Can somebody explain how I'm supposed to run
> these files without using chmod to change the permissions back
> temporarily?
You
Hi,
I notice Werner recently changed the permissions on a lot of files,
including makelsr.py. Can somebody explain how I'm supposed to run
these files without using chmod to change the permissions back
temporarily?
Cheers,
Neil
___
lilypond-devel mai
14 matches
Mail list logo