Fix vs2019 & namespace for install targets #349
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Three minor changes related to my recent fixes for vcpkg and Windows builds
First, the namespace for the export target should be
s2::
, nots2
. Otherwise the downstream imported target becomess2s2
instead ofs2::s2
, which is the actual convention. Sorry, this was a result of my inexperience with the details of building these configs as opposed to consuming them.Second, I failed to include put the absl dependency into the exported exported CMake config for downstream projects. This is necessary because absl is part of the public interface for s2, and thus will be a dependency of any downstream project. The VCPKG dependency mechanism already ensures that absl will be built and installed if s2geometry is requested, but this change is requires to avoid downstream packages having to explicitly call
find_dependency(absl CONFIG)
before using the s2 package.Lastly, the file
src/s2/s2lax_polygon_shape.cc
uses the "terse" form of static_assert, which is technically a part of the C++17 standard, while the project is marked as C++14 compliant. It appears that almost every compiler, including MSVC 2022, supports the terse form even without a C++17 flag except MSVC 2019. MSVC 2019 generates an error causing S2 to fail to build on that platform, which unfortunately is one of the CI targets for the downstream project I'm working on.Also, if we could push a v0.11.1 tag for these fixes, that would enable me to fix the vcpkg version without creating new patches there. I'd really appreciate it.
Cheers.