Re: llvm34 still needs work on header detection

David,
      Did you ever look at the APPLE LOCAL changes in their own clang
compiler sources at
http://opensource.apple.com/source/clang/clang-503.0.38/src/tools/clang/lib/Frontend/InitHeaderSearch.cpp?
The diff for that file against the one in the stock cfe 3.4.1 sources is…

--- lib/Frontend/InitHeaderSearch.cpp 2013-11-15 13:07:59.000000000 -0500
+++ lib/Frontend/InitHeaderSearch.cpp.apple 2014-05-25 09:11:01.000000000
-0400
@@ -1,3 +1,4 @@
+InitHeaderSearch.cpp   [plain text]
 //===--- InitHeaderSearch.cpp - Initialize header search paths
------------===//
 //
 //                     The LLVM Compiler Infrastructure
@@ -47,7 +48,6 @@
   bool HasSysroot;

 public:
-
   InitHeaderSearch(HeaderSearch &HS, bool verbose, StringRef sysroot)
     : Headers(HS), Verbose(verbose), IncludeSysroot(sysroot),
       HasSysroot(!(sysroot.empty() || sysroot == "/")) {
@@ -338,8 +338,58 @@
     break;
   }

-  if ( os != llvm::Triple::RTEMS )
+  if ( os != llvm::Triple::RTEMS ) {
+    // APPLE LOCAL: On Darwin, include the toolchain include directory in
the
+    // default include search list. Since we have a split between the
toolchains
+    // and the SDK, we need a place for tools to be able to drop headers
+    // (resources) that can be used with any SDK, for example in generated
+    // files.
+    //
+    // This functionality is currently only used to support flex's
FlexLexer.h
+    // file. See:
+    //
+    //   <rdar://problem/13135439> Include toolchain include directory in
+    //   default header paths (for FlexLexer.h)
+    //
+    // for more information.
+    //
+    // We compute the toolchain include directory relative to the resource
+    // directory, so that it works with -ccc-install-dir properly. The
resource
+    // directory follows the convention "../usr/lib/clang/<version>" so
+    // "<resource_dir>/../../../include" is the toolchain include
directory.
+    StringRef P = HSOpts.ResourceDir;
+    P = llvm::sys::path::parent_path(P);
+    P = llvm::sys::path::parent_path(P);
+    P = llvm::sys::path::parent_path(P);
+
+    // If the last component is a '..' remove it, this is important
because the
+    // driver sometimes forms the resource path with a '..' in it.
+    if (llvm::sys::path::filename(P) == "..") {
+      P = llvm::sys::path::parent_path(P);
+      P = llvm::sys::path::parent_path(P);
+    }
+
+    // Only add this directory if the compiler is actually installed in a
+    // toolchain or the command line tools directory.
+    if (P.endswith(".xctoolchain/usr") ||
P.endswith("/CommandLineTools/usr")) {
+      AddUnmappedPath(P + "/include", ExternCSystem, false);
+
+      // If this is a toolchain directory, but not the default one, also
add the
+      // default. See:
+      //
+      //   <rdar://problem/14796042> FlexLexer.h is missing from
command-line
+      //   tools and SDKs.
+      if (P.endswith(".xctoolchain/usr") &&
+          !P.endswith("/XcodeDefault.xctoolchain/usr")) {
+        P = llvm::sys::path::parent_path(P);
+        P = llvm::sys::path::parent_path(P);
+        AddUnmappedPath(P + "/XcodeDefault.xctoolchain/usr/include",
+                        ExternCSystem, false);
+      }
+    }
+
     AddPath("/usr/include", ExternCSystem, false);
+  }
 }

 void InitHeaderSearch::
@@ -376,6 +426,11 @@
       AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2.1",
                                   "arm-apple-darwin10", "v6", "", triple);
       break;
+
+    case llvm::Triple::arm64:
+      AddGnuCPlusPlusIncludePaths("/usr/include/c++/4.2.1",
+                                  "arm64-apple-darwin10", "", "", triple);
+      break;
     }
     return;
   }
@@ -475,17 +530,15 @@
     if (HSOpts.UseLibcxx) {
       if (triple.isOSDarwin()) {
         // On Darwin, libc++ may be installed alongside the compiler in
-        // include/c++/v1.
+        // lib/c++/v1.
         if (!HSOpts.ResourceDir.empty()) {
           // Remove version from foo/lib/clang/version
           StringRef NoVer =
llvm::sys::path::parent_path(HSOpts.ResourceDir);
           // Remove clang from foo/lib/clang
-          StringRef Lib = llvm::sys::path::parent_path(NoVer);
-          // Remove lib from foo/lib
-          SmallString<128> P = llvm::sys::path::parent_path(Lib);
-
-          // Get foo/include/c++/v1
-          llvm::sys::path::append(P, "include", "c++", "v1");
+          SmallString<128> P = llvm::sys::path::parent_path(NoVer);
+
+          // Get foo/lib/c++/v1
+          llvm::sys::path::append(P, "c++", "v1");
           AddUnmappedPath(P.str(), CXXSystem, false);
         }
       }
@@ -703,3 +756,4 @@

   Init.Realize(Lang);
 }
+

Of particular interest here is Apple's removal of the code under section…

           // Remove clang from foo/lib/clang
-          StringRef Lib = llvm::sys::path::parent_path(NoVer);
-          // Remove lib from foo/lib
-          SmallString<128> P = llvm::sys::path::parent_path(Lib);
-
-          // Get foo/include/c++/v1
-          llvm::sys::path::append(P, "include", "c++", "v1");

which would have the compiler look for the libc++ headers in
/usr/lib/c++/v1 rather than /usr/include/c++/v1 as the stock sources from
llvm.org currently do.
     So on darwin12, we need…

+          SmallString<128> P = llvm::sys::path::parent_path(NoVer);
+
+          // Get foo/lib/c++/v1
+          llvm::sys::path::append(P, "c++", "v1");

but on darwin13, we need the variation…

+          SmallString<128> P = llvm::sys::path::parent_path(NoVer);
+
+          // Get foo/lib/c++/v1
+          llvm::sys::path::append("/Library/Developer/CommandLineTools", P,
"c++", "v1");

for the libc++ headers to be found.
                    Jack


On Sun, May 25, 2014 at 12:52 AM, Jack Howarth <[email protected]>wrote:

> David,
>        Since fink assumes that the user will have installed the command
> line tools, we should use those locations for the c++ headers. However,
> because fink has a binary distribution again, llvm34 should have a post
> installation script in the clang34 split-off that checks for these expected
> system c++ header directories and if they aren't present either throws an
> error in the package installation or perhaps even invokes 'xcode-select
> --install' to automatically install the missing command line tools.
>                   Jack
>
> On Sunday, May 25, 2014, Jack Howarth <[email protected]> wrote:
>
>> David,
>>      We still have one major issue to address on the llvm34 packaging for
>> 10.8 and 10.9. While on 10.7, clang++-3.4 automatically finds the c++
>> headers, this isn't the case yet for the later OS releases.
>>
>> On 10.8, the libc++ headers are stored in…
>>
>> /usr/lib/c++/v1
>>
>> whereas the libstdc++ headers are stored in…
>>
>> /usr/include/c++/4.2.1
>>
>> On 10.9,  the libc++ headers are installed with the Command Line Tools in…
>>
>> /Library/Developer/CommandLineTools/usr/lib/c++/v1
>>
>> whereas the libstdc++ headers are stored in the same location as in 10.8.
>> of…
>>
>> /usr/include/c++/4.2.1
>>
>> I am unfamiliar with how clang sets these paths. Hopefully we can have
>> the correct default locations added for both -stdlib=libc++ and
>> -stdlib=stdlibc++ for each OS release.
>>                Jack
>>
>

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs

_______________________________________________
Fink-devel mailing list
[email protected]
List archive:
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel