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

[Ryan Schmidt]

On Jan 21, 2009, at 04:31, Rainer Müller wrote:

> MacPorts wrote:
>> #18128: Enhancement to distinguish between Apple and non-Apple  
>> compilers
>> ------------------------------ 
>> +---------------------------------------------
>>  Reporter:  mlk@…             |       Owner:  macports-tickets@…
>>      Type:  enhancement       |      Status:  new
>>  Priority:  Normal            |   Milestone:  Port Enhancements
>> Component:  ports             |     Version:  1.7.0
>>  Keywords:                    |        Port:
>> ------------------------------ 
>> +---------------------------------------------
>>  I've recently found and corrected an issue on at least three port
>>  (tuntaposx, macclipboard-gimp, and macfile-gimp) which  
>> ''require'' 'gcc'
>>  (or 'g++') be an Apple compiler but were instead using just  
>> 'gcc' (first
>>  in the PATH); this issue surely exists in other Ports.  The 'fix'  
>> seems to
>>  be reinplace 'gcc' with '${configure.cc}' wherever needed (ditto  
>> for 'g++'
>>  with '${configure.cxx}' etc.) .
>>
>>  There should be a better way, e.g., use '${configure.apple_cc}'  
>> for those
>>  ports which require Apple's 'cc', and then have a pre-defined  
>> default
>>  (e.g., '/usr/bin/cc' , etc.) which can be overridden in the  
>> Portfile if
>>  desired but must ''always'' provide an Apple compiler.
>>
>>  There are plenty of ports which do not require Apple's gcc, and  
>> hence IMHO
>>  it makes sense to provide both configure.cc and  
>> configure.apple_cc in
>>  order to allow ports access to whichever makes the most sense, to
>>  distinguish between them.
>>
>>  Is something like this already in place?  If so, then at least  
>> these three
>>  ports' Portfile's should be updated; if not, then IMHO it should be
>>  considered.  Thanks for listening. - MLD
>
> 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.
>
> 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".