> On Oct 8, 2019, at 1:59 AM, Ryan Schmidt <[email protected]> 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
