Can't access configure.env in portfile
ryandesign at macports.org
Thu Jan 28 23:20:36 PST 2010
On Dec 11, 2009, at 16:36, Joshua Root wrote:
>> Yes, but if you set (rather than append to) configure.env in a portfile, you overwrite the default environment.
> Can't say I've ever encountered this. Steps to reproduce?
Just to provide closure on this question, I was wrong about my statement above. There was a disconnect between my mental model of how configure.env works and how it actually works. I had assumed it behaved like our other variables -- like configure.universal_args, build.target, destroot.destdir, distfiles, and so forth -- which come pre-populated with some default value, which can be overwritten by the portfile if necessary, or appended to or deleted from. Similarly, portgroups often set up dependencies, as does MacPorts base itself if you use directives like use_autoconf, which ports can append to or delete from. Portfile authors must be careful, however, not to overwrite dependencies or other settings made by a portgroup. Presumably this danger is a reason why we have variables like configure.pre_args; if we didn't, and instead we had set the default --prefix argument in configure.args, portfile authors would overwrite configure.args instead of appending to it and the default prefix argument would be lost.
So I needed to adjust my conceptions to realize that configure.env serves a similar function to configure.args: where configure.args is for portfile-specific configure arguments, which don't overwrite the standard configure arguments in configure.pre_args, so, too, configure.env is for portfile-specific environment variables, which don't overwrite the standard environment variables -- which, unlike the standard configure arguments, unfortunately aren't represented by any portfile-accessible variable.
I note, though, that the consequence of a portfile inadvertently overwriting the standard --prefix argument would be immediately noticeable by the software appearing in /usr/local instead of prefix. In contrast, the consequence of a portfile inadvertently overwriting dependencies or other settings made by a portgroup are much more likely to go unnoticed; I'm sure we have lots of ports in our tree right now that use a portgroup and overwrite a vital setting without realizing it. It's probably a good thing that MacPorts handles the default environment variables outside of configure.env, since overwriting them could have similarly hard-to-notice consequences. But I do sometimes wish for the ability to access them from a portfile, for example through something like a configure.pre_env variable. (A similar solution could be considered for base- and portgroup-declared dependencies: pre_depends_lib, anyone?)
More information about the macports-dev