Skip to content

Don't include experimental/optional if on Apple clang 11 #191

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

Closed
wants to merge 1 commit into from

Conversation

shaglund
Copy link
Contributor

@shaglund shaglund commented Oct 9, 2019

In Apple clang 11 (Xcode 11) experimental/optional emits a warning that it has been removed, i.e building with xcode 11 fails as it seems experimental::optional is available.
This PR fixes that by not setting MODERN_SQLITE_EXPERIMENTAL_OPTIONAL_SUPPORT if building with Apple clang 11 or above.

@zauguin
Copy link
Collaborator

zauguin commented Oct 9, 2019

Thanks for your PR. I want to release the dev branch soon(TM), so could you move this over there? (Maybe you could also test if that branch generally works in Apple systems, especially string_view might have similar problems?)

Also I am very sorry, but I have to loose some words on how we got into this situation in the first place:

rant (Not about you but about these broken by design "standard libraries")

[rant on]
Why would anyone, ever provide such headers? We have lots of feature test macros in C++ such that this whole nonsense of testing the Compiler/Library version really shouldn't be necessary anymore. But that seems to be too easy. Instead, we can only use such macros after including the header (Why is that anyway???) but including the header breaks too because some people think they should provide headers which don't actually do what they promise. If Apple truly thinks that their users need a special warning and can't take the hint when their compiler says experimental/optional not found or similar, they can patch their compiler and add special diagnostics or patch __has_include to not find files which are basically empty or ... But no, everyone has to provide weird headers, making __has_include basically useless, the feature testing macros are hidden in the headers, making them basically useless and we are back at listing supported/unsupported Compiler version.

At this point we probably can give up any hope that this will ever change. Even if the committee would add a reliable way for feature detection, compiler/library vendors will probably just circumvent it too.
[rant off]

But that's the world we live in, so we have to deal with it.

@shaglund
Copy link
Contributor Author

I applied the fix on the dev branch and it built fine in both my c++14 project and the included unit tests. I'll create a new PR for dev

@shaglund shaglund closed this Oct 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants