implementation of configure.env-append

[Ken Cunningham]

I wouldn't suggest raising an error. It's certainly useful to do at times.
Lots of software doesn't run a configure phase, for example.

I still don't think we have this properly sorted out. Look at what Marcus
had to do here, for example <
https://github.com/macports/macports-ports/pull/5463/commits/cb46b2b8c4bcb0f2a6550c87776699ba944dfda3
>.

Perhaps **that** is the solution we need -- skip sending in ${configure.xyz}
in the build lines (which don't get fleshed out properly) and send in  the
env var directly (which does).

Could probably do away with a lot of cruft in Portfiles with that method.
K


On Tue, Oct 8, 2019 at 9:25 AM Blair Zajac <blair at orcaware.com> wrote:

>
>
> > On Oct 8, 2019, at 1:59 AM, Ryan Schmidt <ryandesign at macports.org>
> wrote:
> >
> >
> >
> > On Oct 6, 2019, at 14:05, Ken Cunningham wrote:
> >
> >> I think I have tried this enough ways to be close, but I just want to
> be certain.
> >>
> >> I want to *append* a value onto an existing environment variable from a
> Portfile. I don’t want to overwrite what is there in the environment
> variable already.
> >>
> >>
> >> adding for example this in the Portfile:
> >>
> >> configure.env-append "LDFLAGS=-Wl,-w”
> >>
> >>
> >> adds my new LDFLAGS onto the existing LDFLAGS in the environment, as
> far as I can tell.
> >>
> >> without:
> >> LDFLAGS='-L/opt/universalnew/lib -Wl,-headerpad_max_install_names
> -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
> -arch x86_64 -arch i386'
> >>
> >> with:
> >> LDFLAGS='-Wl,-w -L/opt/universalnew/lib
> -Wl,-headerpad_max_install_names
> -Wl,-syslibroot,/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk
> -arch x86_64 -arch i386'
> >>
> >>
> >> So that works (better than I initially thought, actually).
> >>
> >>
> >> However, as we previously noted in another ticket exploring this:
> >>
> >> ${configure.ldflags}
> >>
> >> does not pick up any of the modifications that are done to LDFLAGS in
> portconfigure.tcl or in Portfile, and so is, practically, seriously flawed:
> >>
> >> pre-build {
> >>   puts ${configure.ldflags}
> >> }
> >>
> >> -L/opt/universalnew/lib -Wl,-headerpad_max_install_names
> >>
> >>
> >> Have we discovered a way in the Portfile to force ${configure.ldflags}
> to be updated to be the same as the fully processed LDFLAGS in
> configure.env?
> >
> > No... it's the other way around...
> >
> > If you want to modify LDFLAGS, do so by modifying configure.ldflags.
> MacPorts will set the LDFLAGS environment variable to the value of
> configure.ldflags before running the configure phase.
> >
> > This is the reason why we have all these configure.* variables: to make
> it easy/possible to set/append/prepend/replace values in commonly-used
> environment variables.
> >
> > Of course this only works for environment variables for which we've had
> the foresight to provide a configure.* variable. If the variable you want
> to do this for doesn't currently have one, and if it's of general enough
> interest, a variable could be added to base for that.
> >
> > For commonly-used environment variables for which we have configure.*
> variables, like configure.ldflags, don't attempt to manually
> set/append/whatever LDFLAGS in configure.env. Instead, use the variable
> MacPorts has provided.
>
> Maybe the MacPorts could raise an error if one attempts to set a variable
> like LDFLAGS outside of configure.* ?
>
> Blair
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20191009/4bf7dc47/attachment.html>