On Oct 24, 2020, at 19:51, Ken Cunningham wrote:
> On Oct 24, 2020, at 3:36 PM, Ryan Schmidt wrote:
>
>> On Oct 24, 2020, at 11:46, Ken Cunningham wrote:
>>
>>> 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.
>>
>> 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.
>
> 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...
>
> 1. User might have set it to something that should be honoured, and expect it
> to be reinstated after the build is done.
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.
> 2. Different parts of the port tree (PortGroups, Portfiles) might try to set
> it to something. The order could be important.
Then they'd better add the paths in the right order? Not sure what you're
getting at.
> 3. The build tree won’t exist when the configure.XYZ flags are parsed, and
> this particular env var often uses the build tree.
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.
> 4. different parts of the build (build, test, destroot) might need it set to
> different things.
Then they should do that?
> 5. Makefiles and Cmake files etc might later try to set it themselves!
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.
> 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).
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?
