[54124] trunk/dports/graphics/tiff/Portfile

[Ryan Schmidt]

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 [1].
>>
>> 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 / 
> Developer,
> so changing without maintainer approval makes sense if that's all  
> that's
> 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 [2]. Until such a time as that
>> is done, we need the code in each portfile, because despite your
>> statement in #20382 [3] 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  
> development
> environment (or whatever that setting is called) which puts the  
> stuff in
> /usr, MacPorts shouldn't care whether Xcode is installed in / 
> Developer,
> /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
> xcode-select).

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.