[PATCH] D59168: [runtimes] Move libunwind, libc++abi and libc++ to lib/clang/ and include/

[Joel E. Denny via Phabricator via cfe-commits]

jdenny added a comment.

In D59168#1479939 <https://reviews.llvm.org/D59168#1479939>, @phosek wrote:

> In D59168#1474715 <https://reviews.llvm.org/D59168#1474715>, @jdenny wrote:
>
> > Does the following match what you have in mind?
> >
> >   $prefix/
> >     include/
> >       c++/
> >         v1/
> >           limits.h
> >           ...
> >       openmp/
> >         v1/ <------ I don't think openmp has anything like this now
>
>
> Iibc++ uses this scheme to allow the possibility of evolving the API but I'm not sure if it's necessary for openmp.


It seems we have roughly the same situation for their ABIs.  That is, for .so files, someone noted that libc++ and libunwind have always used the same version, .1, and openmp doesn't use a version (except in Debian packages).  In other words, for each of these three, a change in ABI compatibility has never been indicated.  For openmp only, it's apparently assumed a change never will need to be indicated (except in Debian packages).

There may be some very good rationale for why openmp is different in this way, but I haven't yet learned what it is.

> 
> 
>>         omp.h
>>         ompt.h
>>         ...
>>   lib/
>>     c++/
>>       $target/
>>         libc++abi.so
>>         ...
>>     openmp/
>>       $target/
>>         libomp.so
>>         ...
>>     clang/
>>       9.0.0/ <----- resource directory
>>         include/
>>         lib/
>>           $target/
>>             libclang_rt.asan_cxx.a
>>             ...
>> 
>>   
> 
> Almost with a small variation:
> 
>   $prefix/
>     include/
>       c++/
>         v1/
>           limits.h
>           ...
>       openmp/
>         omp.h
>         ompt.h
>         ...
>     lib/
>       $target/ <--- This way we don't have to duplicate $target in each subdirectory

We duplicate c++, openmp, etc. in each $target instead.  If you have only one target, I guess that's better.  Otherwise, does it matter?

> and it matches the layout of the resource directory

Does the resource directory have any subproject directories, like c++, openmp, etc?  If not, then it matches just as well either way.  You just remove the level of subproject directories, right?

>     c++/
>       libc++abi.so
>       ...
>     openmp/
>       libomp.so
>       ...
>   clang/
>     9.0.0/
>       include/
>       lib/
>         $target/
>           libclang_rt.asan_cxx.a
>           ...
> 
>   WDYT?

To be clear, I'm not opposed to your proposals.  I'm just trying to understand the relative advantages.  Thanks.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59168/new/

https://reviews.llvm.org/D59168