Closed gillins closed 1 year ago
Given the project name and the Kealib
target name, it might have more sense to create Kealib
CMake package with a Kealib::Kealib
target.
Or is this something which would be still considered worth adopting?
Given the project name and the Kealib target name, it might have more sense to create Kealib CMake package with a Kealib::Kealib target.
Agreed. Perhaps we can change this for 1.6.0 (I'm hoping to push out 1.5.3 soon)? 1.6.0 will have some larger changes so that would be a good time to rename.
It might be possible to have both in 1.5.3, and then remove the other one in 1.6.0.
It might be possible to have both in 1.5.3, and then remove the other one in 1.6.0.
That's a good plan. Are you happy to create a PR for this?
I can do that. With your indication of acceptance, I can test this in the vcpkg port as part of a fix which includes a usage synopsis. And I would prefer to never document anything else ;-)
However, to minimize impact, I suggest two steps:
libkea
config/namespace stuff, and move to Kealib-only.Sounds good. We'd also have to submit something to GDAL that looks for the new target, but can also try the old one (for people still on older kealib). Not sure if this is possible?
We'd also have to submit something to GDAL that looks for the new target, but can also try the old one (for people still on older kealib). Not sure if this is possible?
This is where I come from: https://github.com/microsoft/vcpkg/pull/35437/files Once Kealib's CMake config is stable, we can look at a GDAL PR.
And use it when building the Python bindings.
Should make it easier for
cmake
projects to link againstlibkea
.