[libcxx-commits] [PATCH] D97572: [libc++] Include <__config_site> from <__config>

[Bjorn Pettersson via Phabricator via libcxx-commits]

bjope added a comment.

In D97572#2835202 <https://reviews.llvm.org/D97572#2835202>, @phosek wrote:

> In D97572#2818674 <https://reviews.llvm.org/D97572#2818674>, @bjope wrote:
>
>> In D97572#2795853 <https://reviews.llvm.org/D97572#2795853>, @bjope wrote:
>>
>>> I added some questions related to this in D103386 <https://reviews.llvm.org/D103386> (as I started to see failures with not finding `__config_site`after that patch, but I guess it is related to this patch).
>>>
>>> We been using `-DCLANG_DEFAULT_RTLIB=compiler-rt -DCLANG_DEFAULT_CXX_STDLIB=libc++` when building clang. And we also use `-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON`.
>>> We also build clang/llc for all targets, but we only build libcxx for a subset of targets (e.g. x86_64-unknown-linux-gnu).
>>>
>>> When I only build libcxx for x86_64-unknown-linux-gnu, I only get a __config_site file for that specific triple inside bin/../include/x86_64-unknown-linux-gnu/c++/v1/__config_site in the build result.
>>> But then when compiling for a target such as powerpc64le-unknown-linux-gnu (the test case added in D103386 <https://reviews.llvm.org/D103386>), when including bin/../include/c++/v1/stddef.h, that wants wants to include <__config_site>, I run into trouble because there is no such header for the powerpc64le-unknown-linux-gnu triple.
>>>
>>> Is this kind of setup totally stupid and unsupported?
>>> (I kind of understand that using libcxx for powerpc64le-unknown-linux-gnu when not building libcxx for that target kind of is like begging for problems, but I doubt the test case should depend on that, or if I override CLANG_DEFAULT_CXX_STDLIB)
>>>
>>> Another problem is that a user was using my clang build together with "--target=x86_64-wrs-linux". This has worked fine in the past, but now when we only get "include/x86_64-unknown-linux-gnu/c++/v1/__config_site" in the compiler-clang install the user get failures about not finding `__config_site`. I could mention that this user is not even interested in linking the program, just using clang for static analysis. But the conclusion is that even for doing static analysis one need to match the target with one of the targets for which we have built libcxx.
>>> Maybe this is as expected? Or maybe it has been forseen?
>>>
>>> Should there perhaps always be some kind of generic `__config_site` that is used if there is not target override?
>>
>> I still have these questions. Is there anyone that could help clarifying this a bit, how is it supposed to work?
>
> I missed your question earlier so I apologize for the belated response.
>
> This is not the scenario that I considered when implementing this change but it makes sense. We could generate a generic fallback `__config_site`, my only concern is that it could potentially mask a case where the target `__config_site` is missing where today you'd get an `include` error whereas with the fallback `__config_site` you might see more subtle issues.
>
> We could put it behind a CMake option that's going to be opt-in, for example `LIBCXX_GENERIC_CONFIG_SITE`, would that work?

Just to understand, the idea is to put the generic file in `include/c++/v1/` and rely on that if there is a target specific override that will be included instead (based on order of include paths)?

I do not have a problem with hiding such a thing behind a cmake option.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97572