Remove the non-standard CC alias for c++

[dim]

Summary

Since r34282 (almost 17 years ago) we have been carrying the alias 'CC'
for 'c++, to invoke the C++ compiler. The original reason in O'Brien's
commit message is "for compatibility with SGI".

This alias is not based on any standard, is not compatible with case
insensitive filesystems, and does not seem to be used by any other
operating system. So let's finally get rid of it.

Test Plan

Do an exp-run, probably. I expect zero breakage.

[dim]

Added one more instance of CC.1.

[theraven]

Thank you!

[dim]

Updated for changes in ObsoleteFiles.inc.

[imp]

CC has been an alias for the default C++ compiler the entire life FreeBSD has had a C++ compiler.

Sure, it isn't based on any "standards" but it is a very de-facto standard that many ports rely on.
FreeBSD isn't the only system to do this. Sun did this for years, as did SGI, and many other folks
that had a C++ compiler based on cfront. IIRC CC was a shell script front end for cfront in at least
the cfront 2.0 and 3.0 time frame. Many ISV's compilersr picked up on this de-facto standard and
have been providing the link for a long time.

[imp]

So "it is icky" likely isn't a good enough reason.

Do a ports run w/o it causing any problems and prove me wrong...

[emaste]

In D1932#49686, @imp wrote:

it is a very de-facto standard that many ports rely on.

Many ports will choose CC if it exists, but I'm not sure they rely on it. Autoconf and cmake builds will try a list and if they pick c++ next they'll be fine.
exp-run requested in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200475

[kib]

On what standard the name of the C++ compiler is based, at all ?
What are supposed benefits of the change ?

I believe I already noted elsewhere to dim that the CC is long-time established name. Not all software built on FreeBSD live in the ports framework. Loosing zero-cost convenience feature is not very smart.

[theraven]

It is problematic for the compiler to differentiate between being invoked as CC and as cc (clang and gcc both have to work on case-insensitive filesystems). The convention to have CC as an alias for c++ comes from some SysV platforms (though not from Linux, which does not install the CC alias). On OS X, cc and CC are the same file, as the filesystem is case preserving but not case sensitive.

As a result of this, we have been carrying around patches to clang to make it detect that it is being invoked as CC for a while, to avoid breaking every single cmake-built C++ program (a few hundred ports) that defaults to CC as the C++ compiler (for Solaris/IRIX compatibility), but will happily fall back to using c++ instead.

Aside from the cost of maintaining this patch, this also adds a place where the obj dir / install sysroot must be on a case-sensitive filesystem, which harms attempts to make FreeBSD cross-buildable from OS X / Windows (we are careful to avoid this requirement for the src tree and have an svn hook to prevent it).

The CC alias does not work on Linux or OS X, so the likelihood of this breaking third-party code is minimal and the pain that it has already caused is nontrivial.

[bdrewery]

+1

'CC' is easily confused with '${CC}' and is difficult to even discuss. So much of the development ecosystem tells people to use 'gcc' or 'g++' anyhow, removing 'CC' is unlikely to cause any issues today.

[dim]

An exp-run was requested in bug 200475. Out of ~25000 ports, only 5 failed, and those have been trivially fixed.
The ports tree no longer requires CC to exist.

[dim]

@imp, so are your concerns now addressed? I didn't expect many ports to fail, and there were just a handful, three of which were actual errors (they indended to run ${CC}, but somebody typo'd CC instead).

[emaste]

What are we doing with this?

[dim]

The exp-run proved that the alias is not really necessary. I think very few people, if any at all, consciously use 'CC' for compiling C++ programs in this day and age. :)

[dim]

We chose to go for a shell script wrapper instead.