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 used in the build process, others are for maintenance... > > 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 > > sufficient reason to keep current stuff in buildscripts. OTOH it > > was convenient for most users to just run the script in buildscripts > > without having to "make -C buildscripts" and call the script in > > out/. > > There are two types of scripts: > > . Scripts which are run by the build process. These *must* > substitute the Python binary path. They have almost never needed this kind of substitution, because nearly all makefile command calls explicitly call the interpreter of a scripts. As we shouldn't build buildscripts/out for nuts, I propose to rename $(buildscript-dir) to buildscripts/out. > . 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. > The only question is whether those two subsets intersect. If one script is used in both building and source tree maintenance, it should remain in buildscripts. 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. 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. > On the other hand, there are already targets `check-translation' and > `update-translation' in Documentation/GNUmakefile; why not use them? > Again, if they are intended to work on an unconfigured source tree, No makefile target can work on an unconfigured source tree: every directory in Lily source tree must have a GNUmakefile that includes make/stepmake.make, so that a complete source tarball can be generated. As a consequence, users who don't build LilyPond but who would like to use makefiles for maintaining a translation must run a failing autogen.sh/configure. > both the scripts and the makefile targets should be moved to another > directory. OK for the scripts, but the makefile targets live in Documentation, and they should remain there. Best, John _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
