
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 21, 2020, at 19:22, Nico Weber <<a href="mailto:thakis@chromium.org" class="">thakis@chromium.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class="">The contract is enshrined in the clang driver. Requiring an install as part of the build/run dev loop seems suboptimal maybe?</div></div></div></blockquote><div><br class=""></div><div>The Clang driver says that there can (not even must) be libc++ headers alongside the Clang __installation__ path. The LLVM build directory is all but an installation path. It's a temporary, dirty directory containing temporary build results. This seems to confirm my first impression that this has never been a "contract", but instead just something people relied upon because it worked. That's fine, but if projects need access to an installed version of the libc++ headers during the build, there's a proper way of doing that.</div><div><br class=""></div><div>Regarding the optimality of requiring an install during the build/run dev loop: we already effectively require one, since we require copying the libc++ headers to <build>/include/c++/v1. So doing it properly by actually calling the installation scripts shouldn't be much of a change, except we'll know what we get is the same headers as when we release libc++ proper.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">Anyhow, is there a reason the headers couldn't keep being copied to builddir/include/... (where they used to be)? From my read of your change, I think your patch is independent of the actual copy destination, so why not just keep the old location? I.e. set LIBCXX_GENERATED_INCLUDE_DIR to LIBCXX_HEADER_DIR/include/c++/v1 ?</div></div></div></div></blockquote><div><br class=""></div><div>That's exactly what we're doing now. I had moved it to <build>/projects/libcxx/include/c++/v1 because it made more sense to avoid cluttering the top-level build directory with libc++ specific stuff, however we now learned that other projects want to be cluttered :-).</div><div><br class=""></div><div>Louis</div><br class=""><blockquote type="cite" class=""><div class=""><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 21, 2020 at 7:15 PM Louis Dionne <<a href="mailto:ldionne@apple.com" class="">ldionne@apple.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br class="">

<br class="">

> On Oct 21, 2020, at 19:05, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank" class="">thakis@chromium.org</a>> wrote:<br class="">

> <br class="">

> Not sure I'd call this an "implementation detail". The build dir used to have clang in 'bin/clang', lib stuff in 'lib/...', and this in 'include/...'. That's also the dir layout when installing, and it means that clang's built-in search logic would find libc++ headers before. That seems like a bad thing to break?<br class="">

<br class="">

<br class="">

I wasn't aware this was a convention at a point -- I must have missed it, or it isn't something that's widely known.<br class="">

<br class="">

In all cases, I would argue that the proper way to create something that looks like an installation root is to actually perform the installation to a directory using the scripts that CMake gives you. You can even do it from within CMake itself. That way, you are guaranteed that the proper installation steps are performed, for example:<br class="">

- Setting up the config_site header properly<br class="">

- Replacing libc++.so by a linker script on platforms that do that<br class="">

<br class="">

So it looks like I broke something that is (or once was) a "contract", however I definitely think that contract should be more explicit. I'll see what I can do to improve the situation there.<br class="">

<br class="">

Louis<br class="">

<br class="">

</blockquote></div>

</div></blockquote></div><br class=""></body></html>