ilya-biryukov added a comment. In https://reviews.llvm.org/D54630#1301283, @arphaman wrote:
> I don't think we want to move the logic to add a libc++ path to the driver. > `-cc1` with `-resource-dir` and `-stdlib=libc++` should still work as before. > In this case the previous patch is better, except it should not set > `InstalledDir` except when needed (e.g. for tooling when working with a CDB > that has an absolute path to the compiler), so when `InstalledDir` is empty > it should fallback to the current logic in `InitHeaderSearch.cpp`. That > should solve the issues we had. Why not? @ldionne made a good point: there is value in keeping the frontend separate from the logic to detect system libraries and other toolchain-specific things. This is how other toolchains do it (Linux, etc.). It's more straightforward to the user (one can inspect the -cc1 args produced by the driver), this is where the logic to detect linker dependencies is. It seems that was also the plan of some developers looking in that area: the test I've edited suggests this should be moved to the driver (`darwin-stdlib.cpp`, it says: If and **when** we change to finding them in the driver ...), there's a bug corresponding bug to do this: http://llvm.org/PR30548. I might not have full information, but my understanding is that `-resource-dir` has a pretty well-defined semantics: it should be used to find the `compiler resources`, i.e. only the buit-in headers and not the C++ standard library. What are the reasons we need to keep the old behavior? Repository: rC Clang https://reviews.llvm.org/D54630 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
