[cfe-dev] Recognize CC and clang-CC?

Dimitry Andric dimitry at andric.com
Sat Nov 9 12:37:18 PST 2013


On 09 Nov 2013, at 16:17, Hal Finkel <hfinkel at anl.gov> wrote:
> ----- Original Message -----
>> On Thu, Nov 7, 2013 at 12:46 PM, Joerg Sonnenberger
>> <joerg at britannica.bec.de> wrote:
>>> On Thu, Nov 07, 2013 at 12:27:13PM -0500, Zhihao Yuan wrote:
>>>> 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.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131109/d44cf879/attachment.sig>


More information about the cfe-dev mailing list