macports and Xcode

[Ryan Schmidt]

On Oct 14, 2008, at 09:55, Rainer Müller wrote:

> Ryan Schmidt wrote:
>
>>> There would be multiple possible solutions:
>>>
>>>  a) Add a "linux" platform to the default sections
>>>     Means selecting a specific gcc version (I wanted to add a
>>>     configuration value to macports.conf anyway, would allow to
>>>     overwrite it). Would only fix Linux and not other platforms
>>>     like *BSD.
>>>
>>>  b) Fallback to gcc in /usr/bin/gcc
>>>     Just assume there is a working gcc in /usr/bin/gcc
>>> (respectivley for
>>>     the other tools) if there is no default for the current platform
>>>
>>>  c) Fallback to gcc in PATH
>>>     Don't use any hardcoded paths, assume gcc is available
>>> somewhere on
>>>     this machine and accessible through PATH.
>>>
>>>  d) Fallback to cc in PATH
>>>     Don't assume every machine provides gcc and use cc from PATH
>>>     (e.g. *BSD machines with pcc or Solaris with Sun CC).
>>>     I am not sure if this option will work well, ports may use gcc
>>>     specific options.
>>>
>>> I would prefer c), but I am asking to confirm that I will not be
>>> breaking something again :-)
>>
>> The problem is only when configure.compiler is blank, right? That can
>> only happen on non-Mac platforms, since on Mac OS X we set
>> configure.compiler to something based on the Mac OS X version. I
>> would add a case to the switch statement to allow configure.compiler
>> to be blank, and in that case, I would say we should do what you
>> propose in b) or c).
>
> Exactly, we have defaults for configure.compiler on Mac OS X but  
> not for
> other platforms. And we also don't have a fallback if there is no
> default defined for the current platform.

Ok, then let us make it so: Allow configure.compiler to be empty (on  
any platform), and if it is, set it to "gcc".

>> Maybe "port lint" also needs to check for valid configure.compiler
>> values.
>
> In my opinion, port lint should only check syntax and format of a
> Portfile and not the values. If we add a check for specific  
> options, we
> begin to double the places where the values are kept. I don't think  
> this
> is feasible

I think we already have port lint code that checks values (like  
complaining e.g. if you set a port's maintainer to  
"nomaintainer at macports.org" instead of "nomaintainer" -- trying to  
reduce spam to that address). But in the case of configure.compiler,  
you're right, it's fine not to check for that in lint.