<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite"><pre style="white-space: pre-wrap; color: rgb(0, 0, 0); font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; widows: 1; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Oct 24, 2020, at 19:51, Ken Cunningham wrote:
><i> On Oct 24, 2020, at 3:36 PM, Ryan Schmidt wrote:
</i>><i>
</i>>><i> On Oct 24, 2020, at 11:46, Ken Cunningham wrote:
</i>>><i>
</i>>>><i> So instead of this method, I will look into running lsearch on *.env, and see if I can sort out how to add some entries if something is already there.
</i>>><i>
</i>>><i> MacPorts base makes this easier for specific variables by offering MacPorts variables to set them. For example configure.cflags to set CFLAGS, configure.pkg_config_path to set PKG_CONFIG_PATH, etc. We could consider offering e.g. configure.dyld_library_path to set DYLD_LIBRARY_PATH.
</i>><i>
</i>><i> That would indeed make things easier — but with some thought I can understand why this particular env var is tricky to handle correctly for the general case...
</i>><i>
</i>><i> 1. User might have set it to something that should be honoured, and expect it to be reinstated after the build is done.
</i>
I didn't remember that DYLD_LIBRARY_PATH was among the small set of environment variables that MacPorts does pass on from the user's shell to the build. MacPorts could certainly set the default value of the hypothetical configure.dyld_library_path to $env(DYLD_LIBRARY_PATH), and ports could then append to it as needed. Of course anything MacPorts does to configure.env, build.env, destroot.env, etc. would only persist for the duration of that phase. MacPorts doesn't need to do anything to "reinstate" the user's value of the env var since MacPorts has never changed it to begin with.
><i> 2. Different parts of the port tree (PortGroups, Portfiles) might try to set it to something. The order could be important.
</i>
Then they'd better add the paths in the right order? Not sure what you're getting at.
><i> 3. The build tree won’t exist when the configure.XYZ flags are parsed, and this particular env var often uses the build tree.
</i>
Doesn't matter provided the path can be computed ahead of time. For example ${workpath} can be computed anytime, even if the path they evaluate to doesn't yet exist.
And if it can't be computed ahead of time, you do what we do in tons of other ports already and compute it in pre-configure, pre-build, pre-destroot, etc.
><i> 4. different parts of the build (build, test, destroot) might need it set to different things.
</i>
Then they should do that?
><i> 5. Makefiles and Cmake files etc might later try to set it themselves!
</i>
Indeed they might, probably for a good reason. If your portfile also has a need to add a path to this variable, then you'll maybe have to patch the build system. MacPorts can't do everything for you automatically. Hopefully the number of ports that need to set this env var is extremely small; it has been so far.
><i> 6. All of that hidden away in the environment where it’s that much harder to see what is going on (or what is broken).
</i>
What are you saying here? That you are dissatisfied that Apple chose to implement DYLD_LIBRARY_PATH as an environment variable instead of as something else? Not much we can do about that. Or that MacPorts does not adequately inform you of what values environment variables are set to? I though it already prints them very clearly. How would you like to see it improved?
</pre></blockquote><br><div>Thanks for taking the time to respond. I know you're very busy. I will read this over in due course and see if there's anything actionable in here.</div><div><br></div><div><br></div></body></html>