Recognize CC and clang-CC?

The upper case CC is a traditional UNIX naming of
C++ compiler. BSDs follow this, and cmake regards
it as the host C++ compiler as well.

The fix is at:

  http://www.freebsd.org/cgi/query-pr.cgi?pr=182442

NetBSD doesn't. I'm moderately sure OpenBSD and DragonFly don't either.
Frankly, I don't know what tradition outside FreeBSD you are talking
about -- pretty much everyone has been using "c++" as canonical name for
the C++ compiler for ages.

Joerg

It's an IRIXism. We're going to be removing CC soon, but for compatibility it would be nice to have this in, incase users decide to install the CC -> clang symlink themselves.

David

Provide a shell wrapper as short term workaround with a blinking red
warning that this is obsolete?

Joerg

This patch is already applied to clang in the FreeBSD tree. It would be nice if it were also applied upstream, so that there are no surprises for people who like CC.

For some reason, CMake prefers CC to c++ when it finds both, and this has caused problems building things that use CMake and C++.

David

I'm sorry I should not mention "BSDs". To my best knowledge, Solaris
has CC command and it's still their official way to invoke C++ compiler.
FreeBSD may be influenced by that.

>> The upper case CC is a traditional UNIX naming of
>> C++ compiler. BSDs follow this, and cmake regards
>> it as the host C++ compiler as well.
>
> NetBSD doesn't. I'm moderately sure OpenBSD and DragonFly don't
> either.
> Frankly, I don't know what tradition outside FreeBSD you are
> talking
> about -- pretty much everyone has been using "c++" as canonical
> name for
> the C++ compiler for ages.

I'm sorry I should not mention "BSDs". To my best knowledge, Solaris
has CC command and it's still their official way to invoke C++
compiler.
FreeBSD may be influenced by that.

Does anyone see any harm in adding 'CC' to the list of C++ aliases? CC is still used to indicate 'C++ mode' on many systems (including current Cray HPC systems, FWIW); and so long as there is not a problem with case-insensitive file systems, it would be unambiguous.

-Hal

Yes, for FreeBSD this was the consensus we ended up with. While 'CC' is an ugly convention in my opinion, there is no real disadvantage or problem in recognizing it as an alias for C++ mode. And it is very easy to do too, since the code to recognize several different variations is already in place.

While we are on this subject, I would like to bring a few other items to attention:

The autoconf build and cmake/ninja build currently result in different outcomes for the installed clang binaries: the autoconf build installs a 'clang' binary and symlinks 'clang-3.4', 'clang++' and 'clang-cl' to it, but the cmake/ninja build installs a 'clang-3.4' binary, and symlinks 'clang', 'clang++' and 'clang-cl' to it.

It would be nice to have both methods resulting in the same installation. Also, I believe hard links would be better, since then the reported program name (when e.g. warnings or errors are emitted) is consistent with what the program was invoked with.

Additionally, can a 'clang-cpp' symlink or hard link be added too? I regularly need this, to set ${CPP} to this executable. (And no, clang -E is not the same :-).

-Dimitry

What about a Windows user who names it CC.EXE? The case insensitivity means that there's no difference between that and cc.exe.

(I don't think doing that is sensible. I'm just curious what would happen.)

Sebastian

There is also still the issue that invoking clang as c89 does not actually select the correct version of the standard. I had some patches a while that got bogged down in review over the question of what invoking clang as cc should do (c89 if you're gcc, c99 for clang currently, undefined [and deprecated since 1997] according to POSIX). I think we've now fixed all of the code in ports not to expect a specific version from cc, so I'll try to resurrect this, update it for the new structure of the driver, and send it for review in the next couple of days.

David

The upper case CC is a traditional UNIX naming of
C++ compiler. BSDs follow this, and cmake regards
it as the host C++ compiler as well.

NetBSD doesn't. I'm moderately sure OpenBSD and DragonFly don't
either.
Frankly, I don't know what tradition outside FreeBSD you are
talking
about -- pretty much everyone has been using "c++" as canonical
name for
the C++ compiler for ages.

I'm sorry I should not mention "BSDs". To my best knowledge, Solaris
has CC command and it's still their official way to invoke C++
compiler.
FreeBSD may be influenced by that.

Does anyone see any harm in adding 'CC' to the list of C++ aliases?

What about a Windows user who names it CC.EXE? The case insensitivity means that there's no difference between that and cc.exe.

Not just Windows. The default filesystem on Mac OS X is also
case-insensitive (but case aware):

$ cLaNg
clang: error: no input files

Alp.

...

Does anyone see any harm in adding 'CC' to the list of C++ aliases?

What about a Windows user who names it CC.EXE? The case insensitivity means that there's no difference between that and cc.exe.

(I don't think doing that is sensible. I'm just curious what would happen.)

Well, it would probably identify itself as a C++ compiler then. :slight_smile: On Windows, I don't think there is any reason to rename it to uppercase. In the worst case, you could just put #ifdef WINDOWS guards around it, which is rather ugly, but does the job.

If that is added, would it be OK to commit the original patch by Zhihao Yuan [1]?

-Dimitry

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=182442&getpatch=1

There have been good arguments both for and against the uppercase CC entry so far but not much in the way of technical solutions addressing concerns about case-insensitive filesystems. So how about this… Assuming we can ignore the clang-CC case, and given that the suffixes array is searched in order, how about adding a single “CC” entry directly after “cc” (instead of before as in the original patch)? This way existing behaviour will be preserved on most systems including Windows / OS X and legacy installations will still be able to identify CC as a C++ compiler: I haven’t tested this and don’t have access to a system where this matters, but this seems like a viable approach to investigate in order to reduce vendor patching in FreeBSD. Alp.

Seems like a fine approach to me, assuming testing doesn't reveal any
problems.

The upper case CC is a traditional UNIX naming of
C++ compiler. BSDs follow this, and cmake regards
it as the host C++ compiler as well.

NetBSD doesn't. I'm moderately sure OpenBSD and DragonFly don't either.
Frankly, I don't know what tradition outside FreeBSD you are talking
about -- pretty much everyone has been using "c++" as canonical name for
the C++ compiler for ages.

It's an IRIXism. We're going to be removing CC soon, but for
compatibility it would be nice to have this in, incase users decide
to install the CC -> clang symlink themselves.

Provide a shell wrapper as short term workaround with a blinking red
warning that this is obsolete?

This patch is already applied to clang in the FreeBSD tree. It would be nice if it were also applied upstream, so that there are no surprises for people who like CC.

For some reason, CMake prefers CC to c++ when it finds both, and this has caused problems building things that use CMake and C++.

There have been good arguments both for and against the uppercase CC entry
so far but not much in the way of technical solutions addressing concerns
about case-insensitive filesystems.

So how about this..

Assuming we can ignore the clang-CC case, and given that the suffixes
array is searched in order, how about adding a single "CC" entry directly
after "cc" (instead of before as in the original patch)?

This way existing behaviour will be preserved on most systems including
Windows / OS X and legacy installations will still be able to identify CC
as a C++ compiler:

On that note, I wonder how large the intersection of {people wanting this
CC behavior} and {people on case insensitive filesystems} is. I would be
surprised if the two sets aren't disjoint.

-- Sean Silva