Closed moritz-h closed 1 year ago
May I ask is there a tendency if these changes will be ok or not? Installing CMake targets for hnswlib would make packaging of downstream C++ libraries with a transitive dependency on hnswlib a lot easier. But if you don't want to change CMake here, I would at least know that downstream workarounds are the way to go in the long run.
Hi @moritz-h, Thank you for the PR and the reminder! I'm open to merging it, but as I'm not very familiar with CMake, I'm a bit concerned about potential negative consequences for users relying on the previous structure. What do you think are the chances of a broken build in such cases?
@yurymalkov The only major breaking change is the updated minimum required CMake version. There should be no changes to users with CMake >= 3.0. But the current CMake in hnswlib master seems to be broken anyway for CMake 2.x, so I assume there are no CMake 2.x users, and this change is not critical. Also CMake 3.0 release was 9 years ago, so should be reasonable to drop 2.x support.
Renaming project(hnsw_lib)
to project(hnswlib)
should be only a cosmetic change. The only edge case I can think of is someone using the variable CMAKE_PROJECT_<PROJECT-NAME>_INCLUDE_BEFORE
to inject CMake code. But this is most likely a constructed theoretical argument, I would not assume anyone is using this here, with this very minimal CMake project. Even then, the worst case would be users must update the variable name. My thought was to clean this up to match the name of the library, but could revert it to hnsw_lib
if you want to avoid any minimal possible change, even in rare edge cases.
Everything else is just adding features, no change for existing users:
HNSWLIB_EXAMPLES
defaults to previous behaviour, therefore users could fully ignore it without anything changed.make install
or cmake --build . --target install
to install the project. This was not possible before, but nothing is changed if users do not explicitly use the install target.hnswlib
has now a namespaced alias hnswlib::hnswlib
, but that does not change the original target and users can choose which to use.I just discovered that the next CMake release 3.27 will print a deprecation warning for projects with compatibility to CMake older than 3.5, see https://cmake.org/cmake/help/git-master/release/dev/deprecate-policy-old.html This is fixed by setting a version range to cmake_minimum_required to explicitly set the project compatible to newer CMake versions.
Cool, thank you! We will merge the PR after @dyashuni will do a quick look at it.
@moritz-h Thank you, looks good
Add CMake install targets to allow installing the library using CMake and allow usage with find_package().
Other changes:
hnsw_lib
tohnswlib
).HNSWLIB_EXAMPLES
to allow enabling/disabling tests and examples explicitly. Option defaults to previous behavior checkingCMAKE_PROJECT_NAME STREQUAL PROJECT_NAME