[MacPorts] #18128: Enhancement to distinguish between Apple and non-Apple compilers

[Ryan Schmidt]

On Jan 21, 2009, at 07:59, Michael Dickens wrote:

> On Jan 21, 2009, at 6:57 AM, Ryan Schmidt wrote:
>> On Jan 21, 2009, at 04:31, Rainer Müller wrote:
>>> There is configure.compiler to choose a specific compiler, but it  
>>> only
>>> exports CC/CXX etc. at the moment. If the Makefile does not  
>>> respect this
>>> and uses 'gcc' from PATH (as in these ports) it does not work.
>
> I was thinking of a 2-pronged approach:
>
> 1) For those ports which use 'gcc' explicitly, use a patch file and/ 
> or reinplace to correct that issue.
>
> 2) Create a new 'configure.apple_cc' or whatever, as a viable  
> option to 'configure.cc', which would be put in via a reinplace  
> (possibly after a patch to create a unique string to reinplace).
>
> Using this approach, one can easily choose which compiler to use  
> for a given circumstance ... even both in a given Port's  
> compilation if wanted.
>
>>> To avoid such problems with CC versus 'gcc' in PATH without  
>>> examining
>>> and patching all ports, we would need the choosen compiler to be  
>>> first
>>> in PATH. So we could create a temporary directory, add symlinks  
>>> to the
>>> choosen compiler to it in the configure phase and then add this  
>>> in front
>>> of PATH. Any access to 'gcc' without absolute path will be the right
>>> compiler.
>>>
>>> Would there be any disadvantages I don't see right now?
>>
>> The path to gcc used to compile the program must be the same as  
>> the path to gcc used to compile the libtool it's using. Remember  
>> we had lots of problems with "unable to infer tagged  
>> configuration" until we realized this and forced various libtools  
>> to rebuild after we changed MacPorts from using "gcc" to using "/ 
>> usr/bin/gcc-4.0".
>
> The 'temporary directory with symlinks' concept might work for a  
> single version of cc/gcc to be used, but not multiple versions (one  
> for 'gcc' and another for 'apple_cc').  Not sure if this matters or  
> not ... just pointing it out.
>
> Another idea: Instead of a temporary directory, one could create a  
> set of scripts - sort of like those used by gcc_select, one per cc/ 
> gcc version -, which set default environment variables to be  
> "correct" (prepending to PATH and/or setting CC, CXX, CPATH,  
> CCFLAGS, CXXFLAGS, and so forth; possibly overloading whatever the  
> user provides) for the selected version of cc/gcc.  This would be  
> executed first thing in a Portfile, via some keyword (if provided)  
> or a default (if no keyword provided).  The user can select  
> "apple_cc_4.0" or "apple_cc_4.2" or "macports_cc_4.2" or whatever  
> is available.  Or something like this.


Ports can already indicate what compiler they want by setting $ 
{configure.compiler}. For example, the default value for this  
variable on Leopard is "gcc-4.0", meaning the GCC 4.0 provided by  
Apple with Xcode. If a port author wanted, they could change this  
variable to "gcc-4.2", meaning the GCC 4.2 provided by Apple with  
Xcode, or to "macports-gcc-4.3", meaning the GCC 4.3 provided by  
MacPorts in the gcc43 port. There are options for every other GCC  
compiler that's available. As far as I know this has been sufficient  
to cover the needs of all ports so far. So I have yet to understand  
what your proposed changes would improve.