>>> 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 [EMAIL PROTECTED] _______________________________________________ macports-dev mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
