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 <bl...@orcaware.com> wrote: > > > > On Oct 8, 2019, at 1:59 AM, Ryan Schmidt <ryandes...@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 > >