<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Nov 21, 2013 at 4:46 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><div class="im">
    <br>
    <div>On 07/11/2013 18:18, David Chisnall
      wrote:<br>
    </div>
    <blockquote type="cite">
      <pre>On 7 Nov 2013, at 18:05, Joerg Sonnenberger <a href="mailto:joerg@britannica.bec.de" target="_blank"><joerg@britannica.bec.de></a> wrote:

</pre>
      <blockquote type="cite">
        <pre>On Thu, Nov 07, 2013 at 05:58:11PM +0000, David Chisnall wrote:
</pre>
        <blockquote type="cite">
          <pre>On 7 Nov 2013, at 17:46, Joerg Sonnenberger <a href="mailto:joerg@britannica.bec.de" target="_blank"><joerg@britannica.bec.de></a> wrote:

</pre>
          <blockquote type="cite">
            <pre>On Thu, Nov 07, 2013 at 12:27:13PM -0500, Zhihao Yuan wrote:
</pre>
            <blockquote type="cite">
              <pre>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.
</pre>
            </blockquote>
            <pre>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.
</pre>
          </blockquote>
          <pre>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.
</pre>
        </blockquote>
        <pre>Provide a shell wrapper as short term workaround with a blinking red
warning that this is obsolete?
</pre>
      </blockquote>
      <pre>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++.</pre>
    </blockquote>
    <br></div>
    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.<br>
    <br>
    So how about this..<br>
    <br>
    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)?<br>
    <br>
    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:<br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>-- Sean Silva</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    <br>
    <code>diff --git a/tools/driver/driver.cpp b/tools/driver/driver.cpp</code><code><br>
    </code><code>index 3a6a09b..6d30eca 100644</code><code><br>
    </code><code>--- a/tools/driver/driver.cpp</code><code><br>
    </code><code>+++ b/tools/driver/driver.cpp</code><code><br>
    </code><code>@@ -222,6 +222,7 @@ static void
      ParseProgName(SmallVectorImpl<const char *> &ArgVector,</code><code><br>
    </code><code>     { "clang-gcc", 0 },</code><code><br>
    </code><code>     { "clang-cl",  "--driver-mode=cl"  },</code><code><br>
    </code><code>     { "cc",        0 },</code><code><br>
    </code><code>+    { "CC",        "--driver-mode=g++" },</code><code><br>
    </code><code>     { "cpp",       "--driver-mode=cpp" },</code><code><br>
    </code><code>     { "cl" ,       "--driver-mode=cl"  },</code><code><br>
    </code><code>     { "++",        "--driver-mode=g++" },</code><br>
    <br>
    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.<br>
    <br>
    Alp.<div class="im"><br>
    <br>
    <br>
    <br>
    <blockquote type="cite">
      <pre>David


_______________________________________________
cfe-dev mailing list
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a>
</pre>
    </blockquote>
    <br>
    </div><span class="HOEnZb"><font color="#888888"><pre cols="72">-- 
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a>
the browser experts
</pre>
  </font></span></div>

<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>