(un)setting environment variables from a Portfile

[Michael Dickens]

In my experience, we don't want QTDIR set when compiling Qt. Otherwise I
would not have included that variable (hack) in the first place. I can't
say what happens if it is set; don't remember any longer; probably Qt
just fails building.

My point was: If you trace the "building_qt#" variable through the
PortGroup (qt4; I assume qt5 too), you'll see an "if" statement:
{{{
if {![info exists building_qt4]} {
    configure.env-append \
        QTDIR=${qt_dir} \
        QMAKE=${qt_qmake_cmd} \
        QMAKESPEC=${qt_qmake_spec} \
        MOC=${qt_moc_cmd}
....
}}}
and another one for "build.env-append ...". Thus, since (nominally)
"building_qt#" is set just in the qt#-mac Portfile, then QTDIR will not
be set for just those ports; for any port -not- setting this variable (a
port with Qt as a dependency), QTDIR will be set -- which is as desired.

If the above doesn't help, then I'm really not sure what you're asking
for. - MLD

On Sun, Jan 11, 2015, at 02:43 PM, René J.V. Bertin wrote:
> There already is a building_qt5, but I don't see your point: that's a
> quick and simple way for the PortGroup file to know that it's being
> included in order to build Qt itself.
> 
> My specific case (turned out to be moot) was that having QTDIR set in the
> environment might undo MacPorts' sandboxing attempts, and let the build
> process pick up another Qt install. I feared that'd be particularly
> troublesome when building Qt, but it turns out that MacPorts already
> unsets the variable, somewhere.