Make VAMP usable as a C++ header-only library #31
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
I'm trying to move to a CPM based approach to using this as a library. The first issue (so far): Including vamp as a package like so: file(
DOWNLOAD
https://github.com/cpm-cmake/CPM.cmake/releases/download/v0.40.1/CPM.cmake
${CMAKE_CURRENT_BINARY_DIR}/cmake/CPM.cmake
EXPECTED_HASH SHA256=117cbf2711572f113bab262933eb5187b08cfc06dce0714a1ee94f2183ddc3ec
)
set(CPM_USE_LOCAL_PACKAGES ON)
include(${CMAKE_CURRENT_BINARY_DIR}/cmake/CPM.cmake)
CPMAddPackage("gh:KavrakiLab/vamp#8105e16e070db72029ee1a658ac793b25bf08742")mkdir -p build/release
cd build/release
cmake ../..I get the following error: CMake Error at /usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find Python (missing: Python_INCLUDE_DIRS Development.Module)
(found suitable version "3.11.2", minimum required is "3.8")
Call Stack (most recent call first):
/usr/share/cmake-3.25/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
/usr/share/cmake-3.25/Modules/FindPython/Support.cmake:3240 (find_package_handle_standard_args)
/usr/share/cmake-3.25/Modules/FindPython.cmake:519 (include)
build/release/_deps/vamp-src/cmake/Dependencies.cmake:2 (find_package)
build/release/_deps/vamp-src/CMakeLists.txt:46 (include)I have two guesses as to fixes:
|
|
I think the version issue is actually just that your system doesn't have the Python development headers installed. It says 3.11.2 is suitable, but that it couldn't find |
|
Seems like no dice - I've checked |
|
Looked around a little - maybe these two are related?
My guess is that something is declared as PUBLIC when it shouldn't be, but I can't say I fully understand how this works or why. |
|
I think this is a problem with the fact that we use CPM for our dependencies... Might be able to fix by marking some includes as private; I'll experiment. |
|
here's a link to a reproducing project: |
|
I manually rewrote my CMakeLists file to include all the transitive dependencies, which is a bit of a hack but it works for now. The latest version is here. I'm running up against a fun little compilation disaster right now: |
|
Figured out the issue. For some reason I also need to manually set if(CMAKE_SYSTEM_PROCESSOR STREQUAL "x86_64")
# Need explicit AVX2 for some MacOS clang versions
set(VAMP_ARCH "-march=native -mavx2")
elseif(CMAKE_SYSTEM_PROCESSOR STREQUAL "aarch64" OR CMAKE_SYSTEM_PROCESSOR STREQUAL "arm64")
# ARM platforms (aarch64 / arm64)
set(VAMP_ARCH "-mcpu=native -mtune=native")
else()
message(FATAL_ERROR "Unsupported architecture ${CMAKE_SYSTEM_PROCESSOR}")
endif()The resulting CMakeLists for my project is a little ridiculous but it seems workable enough for now. |
|
@claytonwramsey The reason |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This PR extends the CMake configuration for VAMP to expose a header-only library of the core implementation, for use in downstream C++ projects.
I have not tested these changes at all yet; they are very likely incomplete and/or buggy.
One thing to consider is how much we want to restructure the project to provide more convenience aliases in the headers vs. in the current binding C++ files.