Any reason why CPPFLAGS not used in compiling?
I noticed that Makefile.pre.in uses the value from the environment variable LDFLAGS but not CPPFLAGS. Any reason for this? ``./configure -h`` lists both (and some other environment variables which are not really used either) so it seems a little misleading to have those listed but to not utilize them. The reason I ask is I plan on having setup.py add the directories specified in both of these environment variables for compiling the extension modules. It would be nice to be able to use the same values as used by the Makefile to build the core, but I can if I must just get the values directly from the environment variables themselves. This should allow for the removal of the direct support for Fink and DarwinPorts. It should also remove any hand-editing needed to get setup.py to pick up any non-standard library and header locations. -Brett
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment variable LDFLAGS but not CPPFLAGS. Any reason for this?
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. Regards, Martin
Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment variable LDFLAGS but not CPPFLAGS. Any reason for this?
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 realize that much. But if you look in configure.in it seems to use the previous value of LDFLAGS every time it is redefined as a base and thus gets its initial value from the environment variable the first time it is tweaked. Not a big deal, though. I will just use the environment variables in setup.py . -Brett
Brett C. wrote:
I realize that much. But if you look in configure.in it seems to use the previous value of LDFLAGS every time it is redefined as a base and thus gets its initial value from the environment variable the first time it is tweaked.
Yes, it would be possible to do the same thing for CPPFLAGS. However, you really need to combine the values. If you assume you don't know anything about the current value of CPPFLAGS, this might get tricky - you might cause build failures if you honor CPPFLAGS too much.
Not a big deal, though. I will just use the environment variables in setup.py .
You shouldn't do this - you do need to consider the values in the Makefile as well. If you think you need both, you should modify configure.in appropriately. Regards, Martin
Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment variable LDFLAGS but not CPPFLAGS. Any reason for this?
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. 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. -Brett
Brett C. wrote:
Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment variable LDFLAGS but not CPPFLAGS. Any reason for this?
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. 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.
It's autoconf that deals with these flags. See the output of "configure
--help".
--
Sjoerd Mullender
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. Whether or not adding @CPPFLAGS@ to the end is the right thing, I don't know. Regards, Martin
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
"Brett C."
I noticed that Makefile.pre.in uses the value from the environment variable LDFLAGS but not CPPFLAGS. Any reason for this? ./configure -h`` lists both (and some other environment variables which are not really used either) so it seems a little misleading to have those listed but to not utilize them.
The whole story of how the compiling/linker flags get set up is a bit of a mess, AFAIK. I don't have the energy or the desire to try to make what we want to happen precise (the hard bit) and then make that happen (probably rather easier).
This should allow for the removal of the direct support for Fink and DarwinPorts.
+lots. I don't trust fink, but need it for latex... Cheers, mwh -- After a heavy night I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc
participants (4)
-
"Martin v. Löwis" -
Brett C. -
Michael Hudson -
Sjoerd Mullender