macports and Xcode

[Ryan Schmidt]

On Oct 13, 2008, at 00:47, Rainer Müller wrote:

> Ryan Schmidt wrote:
>> On Oct 12, 2008, at 04:01, Emmanuel Hainry wrote:
>>> DEBUG: Executing org.macports.configure
>>> Error: Target org.macports.configure returned: Invalid value for
>>> configure.compiler
>>>
>>> My way of dealing with that was to modify a few lines in
>>> portconfigure.tcl: there's a
>>> switch -exact "${os.platform} ${os.major}" {
>>> block that sets configure.compiler for the different darwins. I
>>> added a
>>> line "default" that sets it as gcc, g++, cpp. Not sure if that is  
>>> the
>>> good way to do however.
>>
>> I have a feeling this is the change that broke that. Do you agree?
>>
>> http://trac.macports.org/changeset/39573
>
> Yes, seems like I broke it.
>
> My intent was to detect errors like
>   configure.compiler gcc42
> which should have been gcc-4.2 and existed in our tree at that time.

I do remember that case, and agree we should have protection against  
that.


> 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).


Maybe "port lint" also needs to check for valid configure.compiler  
values.