Enhancement to distinguish between Apple and non-Apple compilers

[michaelld (Michael Dickens)]

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

[ryandesign (Ryan Carsten Schmidt)]

For the record: We've had ​a discussion about this on macports-dev now, and explained to Michael about how ports can set configure.compiler if they want a particular gcc compiler, otherwise they get the default Apple compiler; how configure.cc et al get propagated to the configure script via environment variables like CC; and that if a particular software does not respect that environment variable at configure time, then it is the responsibility of the port maintainer to ensure that configure.cc still gets used, using methods such as setting the CC environment variable during the build phase too or if necessary by reinplacing in the Makefile.