[PATCH] D26375: [libc++] Compare to libc++ source directory for out-of-source check

[Shoaib Meenai via cfe-commits]

smeenai added a comment.

In https://reviews.llvm.org/D26375#588949, @beanz wrote:

> This patch doesn't make sense to me.
>
> In an in-tree build `CMAKE_SOURCE_DIR` would be the LLVM source directory which shouldn't match your `CMAKE_BINARY_DIR`.
>
> In an out-of-tree build `CMAKE_SOURCE_DIR` would match the libcxx sure directory, which shouldn't match `CMAKE_BINARY_DIR`.
>
> In an out-of-tree build `CMAKE_SOURCE_DIR` and `CMAKE_CURRENT_SOURCE_DIR`, and for an in-tree build (where they would be different) there should be no situation where the `CMAKE_CURRENT_SOURCE_DIR` could possibly be equal to the current source directory unless the user does something *really* strange.
>
> By *really* strange I mean a workflow that involved checking out LLVM, and libcxx, then configuring LLVM from inside the libcxx directory. If we're looking to capture that kind of situation (configuring a build inside an arbitrary directory in the source tree) our existing mechanisms are insufficient in a great many ways, so I don't think we should go down that path.
>
> If you think this patch is important can you please explain the specific cases where this catches errors that the current code doesn't?


My reasoning was that conceptually, it makes sense for libc++ to be concerned about its own source tree as far as out-of-source builds go. When libc++ is build in-tree, LLVM's build system already takes care of ensuring that the build directory is not the LLVM source directory, so it's redundant for libc++ to do the same.

I don't feel strongly about this though, and from your comment it sounds like I may have just misunderstood the point of this check (i.e. the redundancy was in fact the intended effect), in which case I'm happy abandoning.


https://reviews.llvm.org/D26375