[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

ldionne added a comment. In https://reviews.llvm.org/D48694#1148718, @EricWF wrote: > As an aside, libc++abi should really live in the libc++ repository. That way > it would always have the correct headers available. But every time I pitch > that idea I get a ton of push back. FWIW, I think I

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit rL336032: [libc++abi] Limit libc++ header search to specified paths (authored by smeenai, committed by ). Herald added a sub

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

smeenai added a comment. In https://reviews.llvm.org/D48694#1148718, @EricWF wrote: > > For whether it makes sense to search for includes in the system path, that > > boils down to @ldionne's question of whether building libc++abi against a > > system-installed libc++ is supported. I actually d

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

EricWF added a comment. > For whether it makes sense to search for includes in the system path, that > boils down to @ldionne's question of whether building libc++abi against a > system-installed libc++ is supported. I actually don't know the answer to > that myself ... @dexonsmith and @EricW

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

smeenai added a comment. In https://reviews.llvm.org/D48694#1146232, @EricWF wrote: > LGTM, but I'm a bit confused. You seem to argue that no system places C++ > headers on the default search paths, but also that it would be a problem if > such a system did. > Why wouldn't the conclusion be tr

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

ldionne added a comment. I guess I'm echoing some of Eric's comments, but does it make sense to build libc++abi against a system-installed libc++? If not, this change makes sense. Repository: rCXXA libc++abi https://reviews.llvm.org/D48694 ___ c

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

EricWF added a comment. LGTM, but I'm a bit confused. You seem to argue that no system places C++ headers on the default search paths, but also that it would be a problem if such a system did. Why wouldn't the conclusion be true? That is, although C++ includes aren't normally found along the de

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

smeenai added a comment. This doesn't map to any command line change; it's purely a CMake thing. It just changes where libc++abi's build system looks for libc++ headers. Before this patch, it would look for a file named "vector" in all the standard system include directories (`/usr/local/includ

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

dexonsmith added a reviewer: ldionne. dexonsmith added a comment. What's the effective change on the command-line? Does this map to `-nostdinc`? To `-nostdinc++`? Repository: rCXXA libc++abi https://reviews.llvm.org/D48694 ___ cfe-commits mail

[PATCH] D48694: [libc++abi] Limit libc++ header search to specified paths

smeenai created this revision. smeenai added reviewers: beanz, compnerd, dexonsmith, EricWF, mclow.lists. Herald added subscribers: cfe-commits, ldionne, christof, mgorny. Right now, when libc++abi is locating libc++ headers, it specifies several search locations, but it also doesn't prevent CMake