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

Richard Smith richard at metafoo.co.uk
Thu Nov 21 13:52:08 PST 2013


On Thu, Nov 21, 2013 at 1:46 PM, Alp Toker <alp at nuanti.com> wrote:

>
> On 07/11/2013 18:18, David Chisnall wrote:
>
> On 7 Nov 2013, at 18:05, Joerg Sonnenberger <joerg at britannica.bec.de> <joerg at britannica.bec.de> wrote:
>
>
>  On Thu, Nov 07, 2013 at 05:58:11PM +0000, David Chisnall wrote:
>
>  On 7 Nov 2013, at 17:46, Joerg Sonnenberger <joerg at britannica.bec.de> <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.
>
>  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:
>
> diff --git a/tools/driver/driver.cpp b/tools/driver/driver.cpp
> index 3a6a09b..6d30eca 100644
> --- a/tools/driver/driver.cpp
> +++ b/tools/driver/driver.cpp
> @@ -222,6 +222,7 @@ static void ParseProgName(SmallVectorImpl<const char
> *> &ArgVector,
>      { "clang-gcc", 0 },
>      { "clang-cl",  "--driver-mode=cl"  },
>      { "cc",        0 },
> +    { "CC",        "--driver-mode=g++" },
>      { "cpp",       "--driver-mode=cpp" },
>      { "cl" ,       "--driver-mode=cl"  },
>      { "++",        "--driver-mode=g++" },
>
> 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.
>

Seems like a fine approach to me, assuming testing doesn't reveal any
problems.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131121/61108621/attachment.html>


More information about the cfe-dev mailing list