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.
