Page MenuHomePhabricator

Allow disabling of filesystem library.
ClosedPublic

Authored by EricWF on Mar 20 2019, 3:20 PM.

Details

Diff Detail

Event Timeline

EricWF created this revision.Mar 20 2019, 3:20 PM

Looks sensible to me, modulo the option description.

CMakeLists.txt
80

This option text is a bit misleading (there's no separate libc++fs.a any longer if I understand it correctly) now.

EricWF marked 2 inline comments as done.Mar 20 2019, 3:37 PM
EricWF added inline comments.
CMakeLists.txt
80

Woops. Thanks for catching that.

EricWF updated this revision to Diff 191596.Mar 20 2019, 3:38 PM
EricWF marked an inline comment as done.
  • Correct a typo.
EricWF accepted this revision.Mar 20 2019, 5:02 PM

Accepting for post-commit review.

We need to unbreak downsteam users.

This revision is now accepted and ready to land.Mar 20 2019, 5:02 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMar 20 2019, 5:04 PM
ldionne reopened this revision.Mar 20 2019, 6:01 PM
ldionne added inline comments.
libcxx/trunk/utils/libcxx/test/config.py
438 ↗(On Diff #191608)

Instead, I think this should be dependent on the platform. I don't see a reason why this would be different from` dylib-has-no-filesystem`.

This revision is now accepted and ready to land.Mar 20 2019, 6:01 PM
EricWF marked 2 inline comments as done.Mar 20 2019, 6:15 PM
EricWF added inline comments.
libcxx/trunk/utils/libcxx/test/config.py
438 ↗(On Diff #191608)

That information is specified at configure time and the build system should respect that choice. I see no value auto-magically detecting it here. If they don't want it to run, they should disable it at configure time.

ldionne added inline comments.Mar 21 2019, 9:40 AM
libcxx/trunk/utils/libcxx/test/config.py
438 ↗(On Diff #191608)

The way I see things, the lit test suite is disjoint from the CMake build configuration. When we run the lit test suite, we run it against a concrete release of the standard library (i.e. release by a vendor shipping the library). It just happens to be very convenient to pretend that libc++-as-shipped-with-LLVM is something that makes sense to test against because it gives us a sane workflow. This is why I'd rather not use switches to turn this-or-that on/off, but instead have the test suite know about various implementation characteristics and work with that.

In other words, instead of saying c++filesystem-disabled, just don't build filesystem into the dylib, and then have a way of telling the test suite that the library you're testing (libc++ trunk without filesystem support) has no support for filesystem.

ldionne closed this revision.Mar 22 2019, 12:57 PM

Eric and I spoke and we agreed on a way to handle disabling subparts of the test suite.