implementation of configure.env-append

[Ken Cunningham]

> > On Tue, Oct 8, 2019 at 9:25 AM Blair Zajac wrote:
> 
> > 
> >> Maybe the MacPorts could raise an error if one attempts to set a variable like LDFLAGS outside of configure.* ?
> 
> Yes, MacPorts could do that. I don't think anybody's tried to write code to do that yet.
> 
> 

and please don’t.


> > 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.
> 
> What you say doesn't make sense. 

Try this language: 

I’m not sure I understand your point...


> If a port doesn't run a configure phase, then what variables are or are not set in configure.env or how they get there makes no difference.

The point was that  it is useful to be able to set a variable like LDFLAGS outside of configure.* and please don’t purposefully break it. 

It is a perfectly sensible point. 

I will say very few outright stupid things. 

> 
> 
> > 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 <https://github.com/macports/macports-ports/pull/5463/commits/cb46b2b8c4bcb0f2a6550c87776699ba944dfda3>>.
> 
> What you show there has nothing to do with environment variables.

It has everything to do with environment variables.

If you look Marcus is passing in the fully-fleshed out environment variables that portconfigure has worked out, in a very useful fashion, rather than trying to recreate portconfigure’s work by doing a lot of useless appending to configure.xyz <http://configure.xyz/> manually.

VIZ. - he removed ${configure.cppflags} and passed in $CPPFLAGS.

That is what I should have always been doing myself, and didn’t think of.


> Variables set in a makefile override any environment variables of the same names set by the user at the command line. But it is possible for a makefile to be written so that a variable is set only if it has not already been set in an environment variable. Variables passed to make as arguments override the variables set in the makefile. So it depends on how the author of the makefile wrote it as to whether it will allow environment variables to be used or not. Arguments passed to make always override makefile variables, but it depends on how the makefile was written as to whether it was designed to accommodate its variables being overwritten. For any port that uses a hand-written or otherwise non-autoconf makefile, the portfile maintainer needs to examine the makefile and pass values to it in the way that it wants. Each situation is different.
> 

That is all true, but not relevant to this discussion.



> 
> MacPorts base provides defaults for an autoconf-based build system. If a port doesn't have an autoconf-compatible build system, it needs to set a "use" variable indicating a different build system (e.g. "use_xmkmf yes") or include a portgroup that accommodates whatever other build system it uses, or if it's a hand-made build system or makefile, then the port needs to do whatever needs to be done itself, like what Marcus did above. Continuing to look at that example, that build system accepts make arguments with names like "CUSTOM_CXXFLAGS". That is not a common variable naming scheme that I've seen used in other makefiles; rather, it's specific to whatever that software author wrote into their makefile so it's fine and good that this portfile needs to do that manually.

So just to not start some useless war over nothing, here’s the final points:

1. passing in  $CPPFLAGS (or similar) is much superior to passing in ${configure.cppflags} (or similar) and I’ll try to do that from now on in any ports where the environment is set up properly.

2. It would be just wonderful if the environment set up so nicely in configure was also available in build and destroot.

That’s all I have to say on this issue. Sorry if I somehow ruffled feathers in doing so.

Ken




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20191012/49105f55/attachment.html>