hintonda added a comment. In http://reviews.llvm.org/D12646#241308, @kubabrecka wrote:
> In what scenario exactly are you seeing an issue? If it's a just-built clang > that can't find C++ headers, then you should just build the libcxx project > alongside. clang++ defaults to -stdlib=libc++ for newer versions of MacOS (see ToolChains.cpp:902), but since there isn't a way to pass corresponding include path via cmake, clang++ doesn't work out of the box, i.e., it only checks /usr/include/c++/v1, not the path relative to the version of clang used to build it. I first noticed it when I tried to run the version of clang-tidy I'd just built and found I had to pass the path for it to find iostream. > This is just a default location of Xcode.app and it's wrong to hardcode it, > because the user can install Xcode to different locations (or have multiple > installations). Even letting CMake find the path will be wrong, because the > location of Xcode is a user's choice. Yes, but if you allow the user to pass the include path via cmake, how could that be wrong? This is equivalent to passing GCC_INSTALL_PREFIX so clang can find the gcc headers for libstdc++. The user can always override it if they want to use a different version, but right now, overriding the location is the only way to make it work. If we're not going to generate a working version using libc++, perhaps we shouldn't override -stdlib=libc++ unless the appropriate headers can't be found. http://reviews.llvm.org/D12646 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
