<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><blockquote type="cite" class=""><h1 style="background-color: rgb(255, 255, 255);" class=""><span style="white-space: pre-wrap;" class="">></span><i style="white-space: pre-wrap;" class=""> On Tue, Oct 8, 2019 at 9:25 AM Blair Zajac wrote:</i></h1><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">><i class="">
</i>>><i class=""> Maybe the MacPorts could raise an error if one attempts to set a variable like LDFLAGS outside of configure.* ?
</i>
Yes, MacPorts could do that. I don't think anybody's tried to write code to do that yet.
</pre></blockquote><div class=""><br class=""></div><div class="">and please don’t.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">><i class=""> 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.
</i>
What you say doesn't make sense. </pre></blockquote><div class=""><br class=""></div><div class="">Try this language: </div><div class=""><br class=""></div><div class="">I’m not sure I understand your point...</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">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.
</pre></blockquote><div class=""><br class=""></div><div class="">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. </div><div class=""><br class=""></div><div class="">It is a perfectly sensible point. </div><div class=""><br class=""></div><div class="">I will say very few outright stupid things. </div><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">
><i class=""> I still don't think we have this properly sorted out. Look at what Marcus had to do here, for example <<a href="https://github.com/macports/macports-ports/pull/5463/commits/cb46b2b8c4bcb0f2a6550c87776699ba944dfda3" class="">https://github.com/macports/macports-ports/pull/5463/commits/cb46b2b8c4bcb0f2a6550c87776699ba944dfda3</a>>.
</i>
What you show there has nothing to do with environment variables.</pre></blockquote><div class=""><br class=""></div><div class="">It has everything to do with environment variables.</div><div class=""><br class=""></div><div class="">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 <a href="http://configure.xyz" class="">configure.xyz</a> manually.</div><div class=""><br class=""></div><div class="">VIZ. - he removed ${configure.cppflags} and passed in $CPPFLAGS.</div><div class=""><br class=""></div><div class="">That is what I should have always been doing myself, and didn’t think of.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">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.
</pre></blockquote><div class=""><br class=""></div><div class=""><div class="">That is all true, but not relevant to this discussion.</div></div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><pre style="white-space: pre-wrap; background-color: rgb(255, 255, 255);" class="">
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.
</pre></blockquote><div class=""><br class=""></div><div class="">So just to not start some useless war over nothing, here’s the final points:</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">2. It would be just wonderful if the environment set up so nicely in configure was also available in build and destroot.</div><div class=""><br class=""></div><div class="">That’s all I have to say on this issue. Sorry if I somehow ruffled feathers in doing so.</div><div class=""><br class=""></div><div class="">Ken</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""></blockquote></body></html>