Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Too hard to use as an ExternalProject #73

Open
adamnovak opened this issue Jul 8, 2020 · 1 comment
Open

Too hard to use as an ExternalProject #73

adamnovak opened this issue Jul 8, 2020 · 1 comment

Comments

@adamnovak
Copy link
Member

@rlorigro tried to use libbdsg as a CMake ExternalProject.

It didn't really work; the ExternalProject dependencies that libbdsg pulls in weren't being installed alongside libbdsg itself when Ryan's CMake project installed libbdsg, and headers and libraries were missing.

The way he actually made libbdsg work as an ExternalProject dependency was to depend on libdsg_easy and make IMPORTED libraries for all the transitive dependency libraries:

https://github.com/rlorigro/GetBlunted/blob/aae419d3c2c338d7722cd4de585e80bfad479f9b/CMakeLists.txt#L145-L198

We need to devise a working tutorial for depending on libbdsg via CMake ExternalProject, ideally not using libbdsg_easy, and add it to the docs.

@adamnovak adamnovak changed the title Too hard to use as an External Project Too hard to use as an ExternalProject Jul 8, 2020
@ekg
Copy link
Member

ekg commented Aug 7, 2020

The key issue is that our CMakeLists.txt isn't installing the header files that we depend on.

For building in another project, it's possible to specifically add the header directories to the includes. That's not ideal, but I've found it workable.

Here's how I do it in smoothxg, for odgi https://github.com/ekg/smoothxg/blob/master/CMakeLists.txt#L79-L93

# odgi
ExternalProject_Add(odgi
  SOURCE_DIR "${CMAKE_SOURCE_DIR}/deps/odgi"
  UPDATE_COMMAND ""
  CMAKE_ARGS "${CMAKE_ARGS};-DCMAKE_INSTALL_PREFIX=<INSTALL_DIR>")
#  INSTALL_COMMAND ""
#  CONFIGURE_COMMAND "")
ExternalProject_Get_property(odgi INSTALL_DIR)
set(odgi_INCLUDE "${INSTALL_DIR}/include")
set(odgi_LIB "${INSTALL_DIR}/lib")
set(dynamic_INCLUDE ${CMAKE_SOURCE_DIR}/deps/odgi/deps/DYNAMIC/include)
set(hopscotch_map_INCLUDE ${CMAKE_SOURCE_DIR}/deps/odgi/deps/hopscotch-map/include)
set(sparsepp_INCLUDE ${CMAKE_SOURCE_DIR}/deps/odgi/deps/sparsepp/sparsepp)
set(flathashmap_INCLUDE ${CMAKE_SOURCE_DIR}/deps/odgi/deps/flat_hash_map)
set(random_dist_INCLUDE ${CMAKE_SOURCE_DIR}/deps/odgi/deps/cpp_random_distributions)

Then these include directories are added to the includes for the excutable later. It's not nice, but it works.

I'm also building a few things that are common (like sdsl-lite) and require libraries to be built. What a mess.

We might also consider dumping all of the header files into a common include file and referring to that everywhere. (I'm hoping no package maintainers are reading this... 😈 )

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants