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

[Rainer Müller]

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?

Rainer