Martin v. Löwis wrote: > Brett C. wrote: > >>> How did you notice that? For LDFLAGS, Makefile.pre.in has >>> >>> LDFLAGS= @LDFLAGS@ >>> >>> This does *not* mean that the value from the environment is used. >>> Instead, it means that configure computes the value of LDFLAGS >>> when it generates Makefile.in. For CPPFLAGS, configure has nothing >>> to compute, so Makefile.pre.in just has the static value for >>> CPPFLAGS. >>> >> >> I am not so sure that is true. Checking configure.in, there is no >> mention of CPPFLAGS anywhere. > > > Right. That's what I meant when I said "has nothing to compute", so > it does not even mention CPPFLAGS. > >> And yet if I modify the definition of CPPFLAGS in Makefile.pre.in to >> ``-I. -I./Include @CPPFLAGS@`` it ends up containing the value I have >> for the environment variable at the end of it. I think the '@@' >> syntax uses a value from configure.in if it is defined else it >> defaults to the value the shell has. > > > Indeed, that seems to be the case. However, absence of @CPPFLAGS@ > means that Makefile.pre will just use the static value from > Makefile.pre.in. > That's basically the functionality I need, so I am going with it. > Whether or not adding @CPPFLAGS@ to the end is the right thing, > I don't know. > Well, we will soon find out. =) My checkin made this change and everything seems fine. If it doesn't work out I will have to create another environment variable to store the value. Michael's desire of getting the Fink and DarwinPorts special casing in setup.py is now solved; setup.py now uses the directories specified in LDFLAGS and CPPFLAGS for compiling the extension modules. I didn't bother with CFLAGS or CC since the former is mostly handled by BASECFLAGS it seems and the latter is specified by arguments to configure. -Brett
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4