This is an archive of the discontinued LLVM Phabricator instance.

[clang] [MinGW] Consider the per-target libc++ include directory too
ClosedPublic

Authored by mstorsjo on Aug 11 2021, 4:51 AM.

Details

Summary

The existing logic for per-target libc++ include directories only
seem to exist for the Gnu and Fuchsia drivers, added in
ea12d779bc238c387511fe7462020f4ecf4a8246 / D89013.

This is less generic than the corresponding case in the Gnu driver,
but matches the existing level of genericity in the MinGW driver
(and others too).

Diff Detail

Event Timeline

mstorsjo requested review of this revision.Aug 11 2021, 4:51 AM
mstorsjo created this revision.
Herald added a project: Restricted Project. · View Herald TranscriptAug 11 2021, 4:51 AM
phosek accepted this revision.Aug 11 2021, 9:56 AM

LGTM

This revision is now accepted and ready to land.Aug 11 2021, 9:56 AM
MaskRay accepted this revision.Aug 11 2021, 10:01 AM
This revision was landed with ongoing or failed builds.Aug 12 2021, 3:28 AM
This revision was automatically updated to reflect the committed changes.

Any chance this patch could be backported onto the LLVM 13 branch? I have been using a per target runtime builds for a few versions now but the functionality has regressed in LLVM 13, which would force me back into a normal single target layout.

Any chance this patch could be backported onto the LLVM 13 branch? I have been using a per target runtime builds for a few versions now but the functionality has regressed in LLVM 13, which would force me back into a normal single target layout.

I presume this should be pretty trivial to backport yes - can you file a bug about it in bugzilla, CC @tstellar and mark it as blocking the 13.0.0 release bug?

In which way was this a regression - I guess clang didn't change here - did libcxx start installing the __config_site file differently during this release?

Any chance this patch could be backported onto the LLVM 13 branch? I have been using a per target runtime builds for a few versions now but the functionality has regressed in LLVM 13, which would force me back into a normal single target layout.

I presume this should be pretty trivial to backport yes - can you file a bug about it in bugzilla, CC @tstellar and mark it as blocking the 13.0.0 release bug?

In which way was this a regression - I guess clang didn't change here - did libcxx start installing the __config_site file differently during this release?

Oh, also, do note that this only fixes the issue for the MinGW driver - this needs to be fixed separately for all drivers it seems (or better - refactor them so they'd use one shared codepath for libc++ includes, fixing it all in one place).

Any chance this patch could be backported onto the LLVM 13 branch? I have been using a per target runtime builds for a few versions now but the functionality has regressed in LLVM 13, which would force me back into a normal single target layout.

I presume this should be pretty trivial to backport yes - can you file a bug about it in bugzilla, CC @tstellar and mark it as blocking the 13.0.0 release bug?

In which way was this a regression - I guess clang didn't change here - did libcxx start installing the __config_site file differently during this release?

Since this release libc++ splits what was previously the __config header into __config_site and __config, where __config_site contains all the defines set at configure time by CMake and gets included by __config. Without this patch the include path to __config_sites directory is missing in per target builds and therefore including any file of libc++ causes a compilation error.