On Oct 9, 2019, at 12:04, Ken Cunningham wrote:
> On Tue, Oct 8, 2019 at 1:59 AM Ryan Schmidt wrote:
>
>> 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.
>>
> Quite right, and that's of course what I usually do. And it works most of the
> time.
>
> But in some cases, ports don't run a configure phase, or it is not fully
> honored due to internal software tricks or malfeasance, or similar. So it is
> necessary to get the extra variables into the environment directly (like the
> port I was working on).
>
> I don't know why it never came to me to pass in the $LDFLAGS directly on
> build line like Marcus did -- seems so obvious now. I'm going to go back and
> see if I can rewrite a few dozen Portfiles that I had to backflip through to
> get it done (all those ports where I test for clang and add the stdlib onto
> the compiler spec come to mind as a starting point, for example).
I'm not sure how what you said relates to what I said.
If your goal is to set the LDFLAGS environment variable in the configure phase,
manipulate configure.ldflags and let MacPorts do it for you, rather than trying
to set LDFLAGS=... manually in configure.env.
If the software you're porting doesn't honor LDFLAGS at configure time, then
the distinction is moot. But it is still valuable to put the LDFLAGS you want
to set into the configure.ldflags variable, since that is its standard storage
place, and then do whatever additional work is necessary to communicate that
variable to the build system, e.g. by using `build.args-append
LDFLAGS="${configure.ldflags} [get_canonical_archflags ld]"` or whatever.
