How to handle libraries with language dependent API/ABI

[MikeGitb]

Some libraries have a different API/ABI depending on the language version they are compiled with.

E.g. abseil is using std::string_view or their own string view depending on wether the standard library version is available or not.

How should this be handled if a) I want to compile the library in a different language version than what the cmake file specifies by default (if any) and b) if I need different versions for different projects.

I guess here the answer to b) is to use different vcpkg instances, but I'm not sure what the best solution would be for a) - maybe feature packages could be used for that purpose.

[ras0219-msft]

Thanks for bringing this up!

In the specific case of libraries which break ABI based on the C++ standards version level, you'll need to use different triplets or different vcpkg instances to manage each different build of the library you'd like. Ideally, the standards version would be set in the triplet (since the triplet "owns" the toolchain) and each package would respect it, though this rule is probably broken more often than followed at the moment.

Further, libraries which are ABI sensitive should encode their ABI into their headers (likely by just embedding the macro setting instead of "sensing" it in the downstream TU) to at least make it possible for consumers to upgrade the language settings.

For now, in the concrete case of abseil, the easiest method is probably to use entirely separate vcpkg instances and just modify the CMakeLists.txt in each to whatever standard version you want. In the future, we can improve it to coordinate better with the triplet as described above.

[MikeGitb]

For now, in the concrete case of abseil, the easiest method is probably to use entirely separate vcpkg instances and just modify the CMakeLists.txt in each to whatever standard version you want.

Is there an easy way to copy the list of installed packages from one vcpkg instance to another?

[ras0219-msft]

Right now, you would need to do something like

./vcpkg list | % { @($_.split(" "))[0] }

which would (in powershell) output a list of just the installed packages.

See also #4067 for a proposed feature to explicitly get this.

[MikeGitb]

Thanks.

[MikeGitb]

FYI: It seems boost will / might run into the same problem:

https://groups.google.com/forum/#!topic/boost-developers-archive/EWG5NVOZo_g

[MikeGitb]

Would you accept a PR that added triplets with defined c++ versions? Many libraries will probably not honor this, but we should try to start somewhere.

[MikeGitb]

Push

[JackBoosY]

@MikeGitb Sorry for late, feel free to create a PR to fix this issue.

Thanks.

[MikeGitb]

@JackBoosY : So your really want me to add new tripplets to vcpkg? If so, which ones would make sense? <base-triplet-name>-cpp14,-cpp17,-cpp20 for all existing triplets?

[JackBoosY]

At present, we can add set(VCPKG_CXX_FLAGS ${VCPKG_CXX_FLAGS} -std=c++17) in triplets/TRIPLET.cmake or set it as a port feature.
Example: https://github.com/microsoft/vcpkg/blob/master/ports/abseil/CONTROL#L9

[MikeGitb]

Sure, but that wasn't the question.

Also, it seems to me, that a cleaner (albeit more complicated) solution would be to add a separate VCPKG_CXX_STANDARD option that is propagated to CMAKE_CXX_STANDARD in vcpkg_configure_cmake (not sure how to handle it in ports that are not using cmake though).