[feature-request] Please, consider a more portable include-header pattern for nonstd-xxx libs

[ngrodzitski]

I want to make a Conan package for this library (for CCI conan-center-index).
And I have an issue with that kind of including nonstd family of libs

quickcpplib/include/quickcpplib/byte.hpp

Line 57 in 9aaddae

#include "byte/include/nonstd/byte.hpp"

These libs exist in CCI, but the include for them would look like this:

#include "nonstd/byte.hpp" 
 // or 
#include <nonstd/byte.hpp> 

It would be great if you either help with it yourself or willing to consider a PR with relevant changes.

[BurningEnlightenment]

I think it'd be acceptable to follow a pattern similar to the status-code inclusion in outcome (see here). However, note that this case differs a bit as byte-lite isn't built and therefore not dragged in via find_package (I believe Niall would like to preserve this behavior for the vendored case).

Alternatively, you could simply require at least C++17 (-DQUICKCPPLIB_REQUIRE_CXX17=ON) and skip the byte-lite dependency altogether.

And by the way there have been bugs with certain gsl-lite/span-lite/byte-lite versions, so please make sure to use those currently referenced and/or include a warning similar to the one displayed by vcpkg:

QuickCppLib and its downstream dependencies Outcome and LLFIO were tested against span-lite version 0.10.3 and byte-lite version 0.3.0. They are not guaranteed to work with newer versions, with failures experienced in the past up-to-and-including runtime crashes. You can pin the versions as verified to work in QuickCppLib's CI in your manifest file by adding:

Lastly, thanks for bringing these libraries to conan 🎉

[ngrodzitski]

Alternatively, you could simply require at least C++17

That was my initial plan (even C++20). My final goal is to make LLFIO package. And I wanted to cut support to C++20, but then it appeared that outcome is already in CCI. It is a single header version (not quite what required for LLFIO), that's fine I can update it so it would be possible use true version (e.g. using conan-package-options), but already existing package specifies it works from C++14 (https://github.com/conan-io/conan-center-index/blob/master/recipes/outcome/all/conanfile.py#L25) so I'd prefer to keep it that way (to argue in PR that now outcome "needs" that breaking change is likely to be hard). So need to go through C++14.

Thanks for the link with an example, I'll try to make PR in a similar fashion.

[ngrodzitski]

@BurningEnlightenment
Would it be possible to switch to https://github.com/martinmoene/optional-lite (exists in conan) instead of https://github.com/akrzemi1/Optional (doesn't exist)?

[BurningEnlightenment]

Would it be possible to switch to https://github.com/martinmoene/optional-lite (exists in conan) instead of https://github.com/akrzemi1/Optional (doesn't exist)?

That's something @ned14 has to decide.
However, why not simply vendor it then? That's what we did for the vcpkg port: https://github.com/microsoft/vcpkg/blob/7509b4ce7b1e0fb6537e33b0b7fe23a76c56736e/ports/ned14-internal-quickcpplib/portfile.cmake#L52-L60

[ngrodzitski]

Such approach is discouraged in Conan: conan-io/conan-center-index#15995 (comment)
And adding yet another "optional" package in 2023 looks odd. And with regard to quickcpplib it already uses nonstd-xxx (aka xxx-lite) libraries.
So why not to do the same for optional...

[ned14]

I'm very keen that package managers use the specific versions of dependencies we depend upon. We did enable vcpkg users to explicitly opt into using the latest vcpkg edition of a dependency, but it's not the default.

Insisting on C++ 17 minimum for LLFIO seems very wise. At some point soon I'll be removing the C++ 14 support, and we've had that deprecation warning for years now. That eliminates the Optional issue.

I see no reason why your LLFIO port couldn't insist on C++ 20 without having any effect on the Outcome port's requirements. Outcome is header only.

I assume Conan has auto patch file support? If you absolutely must use the Conan edition of a dependency, you can have an auto patch file replace the use of the git submodule editions with the Conan ones.

[BurningEnlightenment]

I see no reason why your LLFIO port couldn't insist on C++ 20 without having any effect on the Outcome port's requirements. Outcome is header only.

The problem is that the Conan outcome package is based on the single header edition, i.e. he needs to replace the existing package with full-fat outcome. Which in turn needs quickcpplib, so he would need to remove C++14 support from the existing package.

So why not to do the same for optional...

Replacing a dependency always comes with the risk of introducing bugs, so there has to be a sufficiently good reason to do so.