Recognize "CC" and "clang-CC" as C++ compiler aliases on FreeBSD

[dim]

Summary

For a few years now, FreeBSD has been carrying around a patch to recognize "CC" and "clang-CC" as progname aliases for g++ mode. I would really like to get this into upstreamed, to eliminate as many custom patches as I can.

I've just put the FreeBSD specific part between #if FreeBSD delimiters, but I suspect other OSes with case sensitive filesystems, and a historic usage of CC as g++ aliases will also want to use this. Those can add additional defines later on.

[joerg]

We had a discussion about the equivalent of this patch in the pkgsrc wrappers recently. It turns out that exactly one out of 12000+ packages depended on CC. As such, I'm not sure if such a hack is really that desirable. Cleaning up FreeBSD ports should be easy enough?

[dim]

As far as I remember, it were certainly more than a few ports that depended on this. Specifically, all ports that were dependent on CMake, since it defaulted to using "CC" for the default C++ compiler for a very long time. This may have been fixed in recent versions of CMake, though.

The problem is that it is primarly historical software which uses CC as its C++ compiler name, and .C as its C++ file extension. That software is very unlikely to get fixed, and it is annoying to force every user change the Makefiles, or whatever is used.

Last time I tried removing the CC alias from FreeBSD, it got added back in https://lists.freebsd.org/pipermail/svn-src-head/2013-October/052643.html after which the consensus seemed to be that it was better to keep it in, since so many old programs rely on it. It's one of those things that is hard to get rid of...

[dim]

I just checked, CMake 3.1.0 *still* defaults to using "CC" for the C++ compiler.

[dim]

Ping.

[theraven]

This isn't required for the (around 700) ports that we have that use CMake, because the ports tree already explicitly sets CMAKE_CXX_COMPILER for all CMake ports, but it is required to make things that users build from source compile on FreeBSD. It might be useful on other platforms - I think Windows is probably the only place where you wouldn't want it (OS X's HFS+ is case preserving, even if it isn't case sensitive, so cc and CC are easy to differentiate).

I'd be in favour of committing it as-is, and if other platforms encounter the issue then they can opt in as well.

[dim]

Chad, you're the owner of the driver, is this OK to commit? No other platform will be influenced by it. :)

[dim]

Ping.

[dim]

Updating this diff for the moving of FindDriverSuffix() to lib/Driver/ToolChain.cpp.

[dim]

Abandoning this in favor of a wrapper shell script, which will call /usr/bin/c++ instead.

lib/Driver/ToolChain.cpp

 const DriverSuffix *FindDriverSuffix(StringRef ProgName) {
   // A list of known driver suffixes. Suffixes are compared against the
   // program name in order. If there is a match, the frontend type is updated as
   // necessary by applying the ModeFlag.
   static const DriverSuffix DriverSuffixes[] = {
       {"clang", nullptr},
       {"clang++", "--driver-mode=g++"},
       {"clang-c++", "--driver-mode=g++"},
+#ifdef __FreeBSD__
+      {"clang-CC", "--driver-mode=g++"},
+#endif
       {"clang-cc", nullptr},
       {"clang-cpp", "--driver-mode=cpp"},
       {"clang-g++", "--driver-mode=g++"},
       {"clang-gcc", nullptr},
       {"clang-cl", "--driver-mode=cl"},
+#ifdef __FreeBSD__
+      {"CC", "--driver-mode=g++"},
+#endif
       {"cc", nullptr},
       {"cpp", "--driver-mode=cpp"},
       {"cl", "--driver-mode=cl"},
       {"++", "--driver-mode=g++"},
   };
 
   for (size_t i = 0; i < llvm::array_lengthof(DriverSuffixes); ++i)
     if (ProgName.endswith(DriverSuffixes[i].Suffix))