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

[Ryan Schmidt]

On Jan 22, 2009, at 08:11, Michael Dickens wrote:

> On Jan 22, 2009, at 4:42 AM, Ryan Schmidt wrote:
>
>> 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.
>
> I had no idea that one could specify the compiler suite in a  
> Portfile; the best I could find was using ${configure.cc}  
> specifically to 'reinplace' a given string to get the correct CC  
> for a port.  I'm sure this feature is documented somewhere, but I  
> couldn't find it (I did look using Google and MacPorts searches  
> before posting this suggestion, really) ... now that you've told me  
> what to look for, I finally found it parsing through < http:// 
> guide.macports.org/#reference.phases.configure >.  Thanks for  
> pointing this feature out to me.

Setting configure.compiler in a portfile causes configure.cc and a  
whole bunch of other variables to be automatically set to  
corresponding values. MacPorts sets CC in the configure phase to be  
the value of configure.cc, and similarly for other variables. If a  
particular software does not observe the CC environment variable  
during the configure phase, then that port must do something with  
configure.cc (for example reinplace it into a Makefile, or pass it as  
CC in build.env) to ensure that it gets used.


> My suggestion is to make 2 different compiler suites available for  
> Ports to use simultaneously: one of Apple's, and one of a non-Apple  
> (via MacPorts or some other means).  I can't imagine a need for  
> more than 2 different compiler suites, but I can imagine using the  
> possibility of using 2 different compiler suites in a given Port:  
> one for general compiling (e.g., macports-gcc-4.3 to get #pragma or  
> similar options available to 4.3 or newer) and another for Apple- 
> specific compiling (for linking and such).  I will admit to never  
> having tried this out directly, just imagining it [though, it is  
> probable that some of the ports I mentioned where we reinplace'd  
> 'gcc' with ${compiler.cc}, 2 different CC compilers were  
> inadvertently used].

In those ports where you see reinplaces of ${configure.cc} being  
added, the situation before that change was likely that the software  
was building with "cc" or "gcc" instead. On unmodified Macs, that  
should be the same as ${configure.cc}. But some users have used the  
program gcc_select to make a different compiler the default on their  
Mac, and this can break some software. That is why MacPorts was  
changed to always use the absolute path to the compiler that we know  
works, via CC=${configure.cc} etc.


>> 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.
>
> If y'all believe that there will -never- (with reasonable  
> probability) be a time when it would be beneficial to have 2  
> different compiler suites (one for Apple and another for non-Apple)  
> available to use simultaneously, then there is no need for my  
> suggestion given what you've written above about selecting a given  
> compiler suite.
>
> Thanks for the info and the quick responses! - MLD

I don't know of a port that currently needs to build some parts with  
an Apple compiler and other parts with another compiler. If such a  
case should arise, then the port can arrange for that to happen. For  
example, the port would not set configure.compiler (thus, Apple's  
compiler will be in configure.cc et al), and for the parts that must  
use a MacPorts gcc, use a patchfile or reinplace to get those parts  
to use e.g. ${prefix}/bin/gcc-mp-4.3, and then declare a dependency  
on e.g. port:gcc43. I don't think we need any changes in MacPorts  
base for this, especially as it's a hypothetical situation so far.