implementation of configure.env-append

[Ken Cunningham]

Yes, basically. I mean, we have about 1500 very carefully written lines of
code in base designed to work out the perfect configure (and build)
environment, and yet because we can't access it during the build,  we have
several hundred ports trying to cobble together a (usually poorly done)
version of the exact same in portfile logic. And I'll volunteer that those
ports (we all know who you are!) are the ones that cause us 99% of our
headaches with no stdlib being called, or the "NotUsingTheRIghtCompiler",
or incorrect (or no) sysrooting, or etc etc etc.

I don't think people should get hung up on the fact that the environment is
set up in something called the "configure" phase -- change the name of the
environment setup procedure to "environment_setup" and then everyone can be
happy with the name, if that has someone overly focused -- the name is not
the point. Heck, even ports that don't use "configure" can still run the
configure logic in base by setting "configure.cmd /usr/bin/true" and get
the environment -- or call the proc directly and get the environment setup.

Just seems a total shame (and big PITA re: tickets) to see all these ports
absolutely struggling to try to do it right, testing for the cxx_stdlib,
checking for clang as the compiler, looking for an SDK somewhere to
manually add to the build line, monkeying around with ldflags, and trying
to remember totally arcane commands for the proper archflag settings that
perhaps 3 people understand and the rest copy/paste, often messing it up,
when base has already done that 100x better.


That is exactly what I'm thinking should be easy -- so easy it's invisible
in the background.


Ken

On Wed, Oct 9, 2019 at 9:00 PM Joshua Root <jmr at macports.org> wrote:

> On 2019-10-10 07:28 , Ryan Schmidt wrote:
> >
> >
> > 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.
>
> I think what Ken is asking for is a way to access the value of each
> environment variable that would ultimately be in the environment when
> running the configure command, in ports that do not actually use
> configure. That's not easy the way things are set up.
>
> - Josh
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20191011/144058f1/attachment-0001.html>