[34218] trunk/dports/lang

[Caspar Florian Ebeling]

>>> Please don't use the "cd" command. It does not exist in MacPorts
>>> trunk and will not exist in MacPorts 1.7.0 and later.
>>
>> What is the whole story to this change? Does "cd" work in 1.6 but
>> not in trunk? Why was it necessary and is no longer? Is this documented
>> somewhere maybe? Just curious because I ran into build problems
>> with this in a very recently changed port, so some configurations
>> apparently do accept it, while trunk does not.
>
>
> The "cd" command changes the working directory for the tcl interpreter, and
> this change lives on until the tcl interpreter stops. This means that if you
> "cd" somewhere in, say, the configure phase, then the interpreter will still
> be in that directory in the build and destroot and activate phases. If a
> portfile relies on this, it can be confusing to people trying to understand
> how a portfile works. There may also be other reasons that I have forgotten
> at this time.

Yes, I share such concerns about runaway side-effects.

> I think it was never intended for ports to use the "cd" command, but many
> port did, and its use went undetected (or those who noticed its use didn't
> think anything of it) until after the release of MacPorts 1.5.0. The "cd"
> command was going to be removed in MacPorts 1.6.0 but there were still so
> many ports using it that "cd" was retained in 1.6.0. But it is absent in
> trunk (which will be 1.7.0 one day). The use of the "cd" command should be
> removed from all ports.

Ok. Maybe a deprecation period would have smoothed things over a bit
more garcefully, but just turning it off makes for a quicker migration ;)
We will see when 1.7 comes out. (Which hopefully it does some day!)

I'll add a few words to RunningTrunk in the wiki, though. Thanks for
the explanation.

Florian


-- 
Florian Ebeling
florian.ebeling at gmail.com