phosek added a comment. In D59168#1480428 <https://reviews.llvm.org/D59168#1480428>, @jdenny wrote:
> 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). They already use `.2` for ABI v2 which is currently considered unstable but some project like Fuchsia already use. There's also an ongoing discussion to stabilize v2 <http://lists.llvm.org/pipermail/libcxx-dev/2019-March/000282.html>. However, this is only affecting the ABI and therefore `.so`, not headers which will continue using v1 as far as I'm aware (since the API is defined by the C++ standard after all). > There may be some very good rationale for why openmp is different in this > way, but I haven't yet learned what it is. @EricWF might have some insight into this. > We duplicate c++, openmp, etc. in each $target instead. If you have only one > target, I guess that's better. Otherwise, does it matter? Not every target may distribute or even support every runtime. For example, we don't currently ship openmp on Fuchsia because we haven't ported it yet. Similarly we don't ship every compiler-rt runtime. >> 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? Not at the moment, but when designing the current resource directory layout, I haven't given this much though to various aspect so I wouldn't take it as indicative. > To be clear, I'm not opposed to your proposals. I'm just trying to > understand the relative advantages. Thanks. That makes sense, I'd like to understand various requirements for different runtimes before settling on the final layout. Updating this patch should be straightforward. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59168/new/ https://reviews.llvm.org/D59168 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
