lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Assorted fixes for macosx 10.2.8


From: Johannes Schindelin
Subject: Re: [PATCH] Assorted fixes for macosx 10.2.8
Date: Fri, 9 Dec 2005 14:30:20 +0100 (CET)

Hi,

On Thu, 8 Dec 2005, Matthias Neeracher wrote:

> 
> On Dec 8, 2005, at 10:26 AM, address@hidden wrote:
> > From: Johannes Schindelin <address@hidden>
> > 
> > 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...





reply via email to

[Prev in Thread] Current Thread [Next in Thread]