-
-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add C++17 support that "just works" via package managers #2462
Comments
I think that may be overstating it. I have yet to see anything indicating that either side agrees there's a problem at all. (I'm not sure I do, either.) The vcpkg people suggested a TWO-line workaround that would solve this for you. The only reason that's not acceptable is your extremely narrow constraint (emphasis mine):
...Meeting that requirement probably involves way more work than the 2-line fix you rejected, so what's the compelling argument in favor of expending all that additional effort? I get that you would "like to..." do that, but to be blunt... why should any of the rest of us care? Beyond vcpkg, there's also the option of using a different package management system. (In choosing to use one, any one, you implicitly incorporate all of its quirks and limitations into your project as well.) As someone mentioned in one of the other threads, Conan packages support an almost limitless array of feature dimensions, and separate packages can be published for any/every combination of them. That means it's possible to choose a specific variant/build that matches your requirements, however complex they may be. vcpkg have explicitly said they don't support that, at least for C++ standard specifically, which may mean that Catch2 should just be considered incompatible with vcpkg. I can't speak for anyone else, but that's not something I'd consider a bug in Catch2. (Or at least, not one I'd expend any effort addressing.) It downloads as source in mere seconds, and compiles locally in... tens of seconds. |
@ferdnyc - Thanks for your reply. If it's as simple as two lines, I have no objection. But I think there's the cost of having to fork the package definition in order to change those two lines, and it's the overhead of having a forked package definition just to get C++17 support that seems problematic to me. Or am I misunderstanding the cost of the workaround? |
And regarding this point:
The main thing I'm hoping to get here, at least to start with, is figuring out how this should work. If vcpkg can't support compiling a simple library with C++17 support, that feels like a problem with vcpkg to me. But I'm hoping both sides can agree, as I think that will help quite a bit with getting whatever vcpkg improvements (if any are needed) to make what I'd hope are fairly simple things work fairly simply. |
vcpkg solved this on their side: |
@davidmatson Other package managers still suffer from the same issue, e.g. Homebrew updated to v3.0.1 but compiles in the default C++14 mode. I think you should reopen the issue and hope that maybe it will get fixed some day. Instead of telling each package maintainer to manually add target_compile_features(Catch2 PRIVATE cxx_std_17)
target_compile_features(Catch2WithMain PRIVATE cxx_std_17) Older compilers like GCC 5 will still work. |
@dimztimz - maybe that's best as a separate issue, since vcpkg was in the title of this one and that's now solved? Your proposed solution sounds good to me, but I don't know enough about any potential disadvantages of doing it that way. |
Opening yet another fourth ticket for the same issue is not any better, I think it is better to reopen this. You can always edit the title. |
I would like to give few arguments why this issue is a real issue. Actually, I will just post recommendations written by others. There is this talk on CppCon named “Don't package your libraries, write packagable libraries!”. In slide 25 there is the following recommendation:
Moreover, in the documentation of Vcpkg there are few recommendations on using vcpkg features which are essentially different compile-time configurations of the same library. In particular I will point to these:
Considering all this, there are 3 solutions for this issue:
|
Couldn't this be trivially fixed by just adding a CMake option like option(CATCH_USE_CPP17 "Use C++17 features by default" ON) if (CATCH_USE_CPP17)
target_compile_features(Catch2 PUBLIC cxx_std_17)
endif() This would also automatically enable |
Catch2 has some features for C++17 that are only exposed if the C++ standard is set to 17. See catchorg/Catch2#2462.
That is not a solution, you are doing the same thing as CMAKE_CXX_STANDARD, but more complicated. |
Catch2 has compile-time bugs if we use it in C++17 code with some of the new C++17 types like string_view. For example the following line will cause bugs: REQUIRE(string_view("abc") == "abc"); The bug is documented in the upstream issue tracker here: catchorg/Catch2#2462 We fix the bug downstream by building Catch2 itself in C++17 mode. Additionally, enable building with GCC 5, the current version does not fail anymore with GCC 5.
Catch2 has compile-time bugs if we use it in C++17 code with some of the new C++17 types like string_view. The bug is documented in the upstream issue tracker here: catchorg/Catch2#2462 . We fix the bug downstream by building Catch2 itself in C++17 mode. Additionally, enable building with GCC 5, the current version does not fail anymore with GCC 5. Modernize CMake invocation.
I would like to see Catch2 do this. If we want we can maintain a way to opt out of C++17 features for the sake of supporting users on exceptionally old compilers but if you ask me I'd rather raise the entire library's language requirement to 17. This lets us remove lots of CMake options, avoids the whole problem this issue points out, and lets us use C++17 language features in the implementation which has the potential to make the library simpler and easier to maintain. |
Description
I'd like to use code such as the following in a project that gets Catch2 via vcpkg and have it just work (not require a port overlay or patch to the vcpkg repo):
Additional context
I thought this was a vcpkg bug, but they've indicated it's an upstream bug:
microsoft/vcpkg#25236
Similar questions have come up here before, but there isn't a solution yet:
#2210
#2046
I'm hoping we can start by getting agreement between Catch2 and vcpkg on what side the right fix would be here. (I think the starting position is both sides think the problem is on the other side, which probably needs to be resolved first in order to get to a solution.)
The text was updated successfully, but these errors were encountered: