ryandesign at macports.org
Wed Jul 22 13:41:57 PDT 2009
On Jul 21, 2009, at 21:09, Bryan Blackburn wrote:
> On Tue, Jul 21, 2009 at 04:16:06PM -0500, Ryan Schmidt said:
>> I reverted this change in r54132. I had deliberately added this code
>> 4 months ago; see #18801 .
>> Do not remove code others have deliberately added to portfiles
>> without discussing the issue first.
>> Do not modify maintained ports without giving the maintainer 72 hours
>> to respond to the issue. The maintainer probably never even saw this
>> ticket since it wasn't assigned to him and he was not Cc'd. If the
>> maintainer timeout policy is too restrictive we can discuss whether
>> it needs to be changed. Perhaps we need to add exemptions for certain
>> kinds of changes.
> Note that the port was broken for installs of Xcode outside of /
> so changing without maintainer approval makes sense if that's all
> being touched.
I had thought MacPorts had never worked with Xcode outside of /
Developer. Also, our current documentation does not list this as a
reason to allow non-maintainer updates. We should allow more non-
maintainer updates; I'll open a new thread about this.
>> The reason I reverted your change is that this check is in over a
>> dozen other ports too and we need a fix that addresses all ports, not
>> just tiff. I would like for the fix to be that a more advanced Xcode
>> version check (taking into account alternate Xcode install locations)
>> is done by MacPorts base; see #12794 . Until such a time as that
>> is done, we need the code in each portfile, because despite your
>> statement in #20382  that users should know that they need the
>> latest Xcode, they demonstrably do not know this. Most of the Xcode
>> version checks currently in portfiles were added because users
>> reported that something did not work, and the reason was their Xcode
>> was too old. To prevent other users from having this issue in the
>> future, the Xcode version check was added to the ports.
> This is probably abusing port groups some, but can we move the
> check to one
> so we don't have all this code repeated in these "over a dozen
> other ports"
> until the check can be done within base instead?
That could be possible. I will look into it.
>> The Xcode version check in these ports is not "faulty"; it merely
>> does not accommodate nonstandard Xcode install locations. To my
>> knowledge, MacPorts has never supported nonstandard Xcode install
>> locations to date, so I think the correct resolution to #20382 for
>> now is to tell the user to install Xcode in the standard location. Or
>> if we can come up with new code that uses xcode-select when available
>> and add that to all the ports that currently check Xcode versions,
>> that could be a solution too.
> As far as I know, as long as Xcode is installed with the Unix
> environment (or whatever that setting is called) which puts the
> stuff in
> /usr, MacPorts shouldn't care whether Xcode is installed in /
> /Volumes/Someplace/Developer, or elsewhere. Or are there other
> references to /Developer beyond this Xcode version check? The new
> developer_dir variable (on trunk) is set to that location by
> default, but
> it can be set in macports.conf (and long-term probably should be
> set using
I was thinking of the fact that developer_dir was just added to
trunk. I don't know what all it's used for.
I was also thinking of the universal SDKs. But in 1.7.x I suppose the
user can specify the path to those in macports.conf, and in trunk
that's been removed and the SDK is only used on Tiger PPC, which
doesn't need developer_dir since Xcode can't be relocated on Tiger.
More information about the macports-dev