Getting the entire configure.cflags variable
dstrubbe at macports.org
Thu Oct 2 15:17:32 PDT 2014
You could alternately try to patch the code to pay attention to CFLAGS. I'm
not sure how complicated that would be in the build system.
On Thu, Oct 2, 2014 at 6:13 PM, Ryan Schmidt <ryandesign at macports.org>
> On Oct 2, 2014, at 4:29 PM, Lawrence Velázquez wrote:
> > On Oct 2, 2014, at 5:13 PM, Ryan Schmidt wrote:
> >> On Oct 2, 2014, at 4:10 PM, Lawrence Velázquez wrote:
> >>> I suspect the idea is to prevent ports from clearing CFLAGS and such.
> >> I think it's more that in many cases -- arch flags for example, or
> which C++ stdlib flag to use -- MacPorts won't know what to put in the
> cflags until after the rest of the port has been processed. What if you
> append something to configure.cflags, then later turn on (or turn off) the
> universal variant? Then the wrong arch flags will be in configure.cflags.
> This is why (as I understand it) MacPorts doesn't put them in until the
> port has been completely evaluated.
> > For my part, when I implemented configure.cxx_stdlib, I was primarily
> thinking about preventing Portfiles from trashing the "-stdlib" argument.
> Augmenting configure.cxxflags seemed preferable to arcane Tcl sorcery.
> But that's just it. The -stdlib arg *isn't* appended to
> configure.cxxflags; it's added to the CXXFLAGS environment variable in
> configure_main; ports have no opportunity to inspect or modify this value.
> I had to manually add code to the pure portgroup to handle
> configure.cxx_stdlib because of this. Any port which sets "use_configure
> no" because it does not use a standard build system like autotools or cmake
> will be similarly affected.
> macports-dev mailing list
> macports-dev at lists.macosforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the macports-dev