Hi, On Thu, 8 Dec 2005, Matthias Neeracher wrote:
> > On Dec 8, 2005, at 10:26 AM, [EMAIL PROTECTED] wrote: > > From: Johannes Schindelin <[EMAIL PROTECTED]> > > > > On Wed, 7 Dec 2005, Graham Percival wrote: > > > > > I don't understand most of these patch, > > > > I'll try to explain: > > > > > > pathsettings: > > > > @echo export PATH=$(PATH) > > > > + @echo export LILYPOND_DATADIR=$(LILYPONDPREFIX) > > > > @echo export LILYPONDPREFIX=$(LILYPONDPREFIX) > > > > @echo export PYTHONPATH=$(PYTHONPATH) > > > > This is needed so that lilypond does not try to use > > /usr/local/share/something, but the files from where lilypond is compiled. > > That makes it definitely unsuitable for general purpose distribution. This > location can be overridden at runtime anyway, can't it? Sorry, this *is* an override. Namely, to make the documentation even if you have a lilypond installed which is an earlier version, and want to "make" the user documentation. I think this very definitely should go in. It fixes a bug. > > > > diff --git a/my-lexer-gcc-3.1.sh b/my-lexer-gcc-3.1.sh > > > > new file mode 100644 > > > > index 0000000..c781409 > > > > --- /dev/null > > > > +++ b/my-lexer-gcc-3.1.sh > > > > @@ -0,0 +1,10 @@ > > > > +#!/bin/sh > > > > + > > > > +cd "$(dirname "$0")/lily" > > > > + > > > > +rm out/lexer.cc 2>/dev/null > > > > +make out/lexer.cc > > > > +mv out/lexer.cc out/lexer.cc.orig > > > > +cat out/lexer.cc.orig | sed 's/^class istream;$/#include <iostream>\ > > > > +using namespace std;/' > out/lexer.cc > > > > + > > > > This is a very simple fix for my very special setup. Unless someone > > verifies that it helps on other platforms, too, I'd rather see it as "it > > helped me, maybe it helps you" hint. > > This is definitely needed on MacOS, since flex generates a file that is not > correct C++ on that particular point (I wonder why, and why this never causes > problems on other platforms). I don't think that it hurts on any platform. You have to start it manually, anyway. > > > > --- a/stepmake/stepmake/compile-vars.make > > > > +++ b/stepmake/stepmake/compile-vars.make > > > > @@ -3,10 +3,14 @@ ARFLAGS = ru > > > > ALL_LDFLAGS = $(LDFLAGS) $(CONFIG_LDFLAGS) $($(PACKAGE)_LDFLAGS) > > > > $(MODULE_LDFLAGS) $(CONFIG_LDFLAGS) > > > > > > > > PIC_FLAGS = -fpic -fPIC > > > > -ifeq ($(MINGW_BUILD),) > > > > -SHARED_FLAGS = -shared > > > > -else > > > > +ifneq ($(MINGW_BUILD),) > > > > SHARED_FLAGS = -mdll > > > > +else > > > > +ifneq ($(DARWIN_BUILD),) > > > > +SHARED_FLAGS = -bundle -flat_namespace -framework Python > > > > +else > > > > +SHARED_FLAGS = -shared > > > > +endif > > > > endif > > > > > > > > o-dep-out = $(outdir)/$(subst .o,.dep,$(notdir $@))# > > > > I agree with Han-Wen that this should go into python-vars.make. > > Actually, the -framework Python should go there, but -bundle -flat_namespace > belongs into compile-vars IMHO. No. The preferred way on Darwin/Mac OS X to make shared libraries is to use "-dynamiclib". I don't know what the python people were smoking when they decided to go with "-bundle -flat_namespace -framework Python", but that does not matter any longer, right? > > > > --- a/stepmake/stepmake/generic-vars.make > > > > +++ b/stepmake/stepmake/generic-vars.make > > > > @@ -111,3 +111,8 @@ endif > > > > ifeq ($(HOST_ARCH),i386-mingw32) > > > > MINGW_BUILD = yes > > > > endif > > > > + > > > > +ifeq ($(HOST_ARCH),ppc-darwin) > > > > +DARWIN_BUILD = yes > > > > +endif > > > > + > > > > I think this is more or less uncontroversial. It defines the variable > > DARWIN_BUILD on Darwin, so that the Makefiles can have special casing for > > Darwin as they have special handling of MinGW. > > Good idea. I should have proposed that a long time ago. Thanks! Ciao, Dscho P.S.: I will now go and look how to solve the python problem cleanly, i.e. different from my current approach... _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-devel
