implementation of configure.env-append

[Ryan Schmidt]

On Oct 9, 2019, at 10:57, Ken Cunningham wrote:

> 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.


> 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. 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.


> 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>.

What you show there has nothing to do with environment variables. That build system presumably does not support environment variables, but does support arguments passed to the make command. So that's why the portfile sends the values in that way.

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.


> 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.


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.