[cfe-dev] RFC: Place libs in Clang-dedicated directories (affects openmp, libcxx, libunwind, compiler-rt)

[Ilya Biryukov via cfe-dev]

> From this point of view, what LLVM_ENABLE_PER_TARGET_RUNTIME_DIR breaks
the tools and the proposed alternative fixes this problem
what  LLVM_ENABLE_PER_TARGET_RUNTIME_DIR *does now *...

On Mon, Feb 25, 2019 at 11:31 AM Ilya Biryukov <ibiryukov at google.com> wrote:

> Using the resource-dir in the header search paths would break tools that
> use compilation database, e.g. clang-tidy and clangd.
> They override the resource-dir as it's very common for them to be built
> from a different revision than the used compiler. They rely on the fact
> that the same standard library can be found with the overridden resouce-dir.
>
> From this point of view, what LLVM_ENABLE_PER_TARGET_RUNTIME_DIR breaks
> the tools and the proposed alternative fixes this problem.
>
> On Mon, Feb 25, 2019 at 11:17 AM Petr Hosek via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On Wed, Feb 20, 2019 at 6:14 PM Joel E. Denny <jdenny.ornl at gmail.com>
>> wrote:
>>
>>> My alternative to LLVM_ENABLE_PER_TARGET_RUNTIME_DIR is the preceding
>>> bullets.  In other words, you wouldn't need to specify
>>> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR because it would effectively be
>>> always on (except the directories might be different than now if the
>>> version locking issue is important, as noted above).  Is that what
>>> you're asking?
>>>
>>
>> That would be my preference. I always hoped that
>> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR would eventually become the default. It
>> would be nice to finish the Darwin support so we can completely deprecate
>> the old layout, but I don't know how far along beanz is in his effort. We
>> should also update openmp to stop using the custom Android-specific runtime
>> layout.
>>
>> There's also the unresolved question of where should libc++ headers and
>> libraries go. Currently, in LLVM_ENABLE_PER_TARGET_RUNTIME_DIR we use the
>> resource dir, but some people expressed the opinion that we shouldn't be
>> using these for libc++ et al. since they're not version-locked to Clang.
>> This is different from what GCC does (e.g. GCC would use
>> $prefix/lib/gcc/x86_64-linux-gnu/8/libstdc++.a) and it's one of the reasons
>> why I used the resource dir for libc++ et al. when implementing
>> LLVM_ENABLE_PER_TARGET_RUNTIME_DIR.
>>
>> So concretely, today LLVM_ENABLE_PER_TARGET_RUNTIME_DIR uses the
>> following layout:
>>
>> headers: $prefix/lib/clang/$version/include(/$triple)(/c++/v1)
>> libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext
>>
>> The alternative that doesn't use resource dir for libc++ would be the
>> following:
>>
>> compiler-rt:
>>   headers: $prefix/lib/clang/$version/include
>>   libraries: $prefix/lib/clang/$version/$triple/lib/$name.$ext
>>
>> libc++, libc++abi, libunwind:
>>   headers: $prefix/include/c++/v1
>>   libraries: $prefix/lib/$triple/$name.$ext
>>
>> Making this change should be trivial, it's the matter of changing three
>> CMakeLists.txt files (libunwind
>> <https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L189>,
>> libc++abi
>> <https://github.com/llvm/llvm-project/blob/master/libcxxabi/CMakeLists.txt#L179>
>> and libc++
>> <https://github.com/llvm/llvm-project/blob/master/libcxx/CMakeLists.txt#L419>)
>> and Clang driver in one place
>> <https://github.com/llvm/llvm-project/blob/master/clang/lib/Driver/ToolChain.cpp#L79>.
>> However, if we're going to make that change, I'd like to get a broader
>> consensus. It'd be also useful to get feedback from libc++ maintainers on
>> this.
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
>
> --
> Regards,
> Ilya Biryukov
>


-- 
Regards,
Ilya Biryukov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20190225/1d9cc011/attachment.html>