Build process fails when using QuEST as cmake subdirectory

[rrmeister]

Setup

This problem appeared while trying to get pyQuEST to compile with QuEST v4. In that setup, QuEST is included in the pyQuEST repository as a submodule and added to the pyQuEST (which also compiles using cmake) build system using cmake's add_subdirectory(). All of the following refers to 3878f03.

Problem

When trying to compile in this setup, the build process for QuEST fails with

In file included from [...]/pyquest/QuEST/quest/src/api/calculations.cpp:9:
[...]/pyquest/QuEST/quest/include/types.h:22:10: fatal error: 'quest/include/config.h' file not found

Checking the compile stages manually, it seems this is caused by a mismatch between the location where config.h is placed at the configure stage and the include path used later at compile time. The file CMakeLists.txt:12 calling config.h.in places the generated config.h in ${CMAKE_BINARY_DIR}/include/quest/include/config.h as per

configure_file(config.h.in "${CMAKE_BINARY_DIR}/include/quest/include/config.h" @ONLY)

while the include path set in the top-level CMakeLists.txt:281 uses (among others) CMAKE_CURRENT_BINARY_DIR

target_include_directories(QuEST
  PUBLIC
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/quest/include>
  $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}>
  $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/include>
  $<INSTALL_INTERFACE:${CMAKE_INSTALL_INCLUDEDIR}>
)

When compiling QuEST by itself, these resolve to the same binary dir, because the at the top level (where the include is set), the CMAKE_CURRENT_BINARY_DIR is the same as CMAKE_BINARY_DIR. Using QuEST in a subdirectory, however, breaks this consistency, because CMAKE_BINARY_DIR resolves to the binary path relative to the parent project, but CMAKE_CURRENT_BINARY_DIR remains relative to the QuEST subdirectory.

Example

Printing some debug info during the build process shows this discrepancy. The file generating config.h sees CMAKE_BINARY_DIR as

[...]/pyquest/_skbuild/macosx-12.0-arm64-3.10/cmake-build

but printing the include paths contains (among others)

$<BUILD_INTERFACE:[...]/pyquest/_skbuild/macosx-12.0-arm64-3.10/cmake-build/QuEST/include>

Notice the extra QuEST directory in the include path, which is where the QuEST repo is contained within the pyQuEST repo.

Potential solutions

The simplest solution would be to just add ${CMAKE_BINARY_DIR} to the include path and leave the rest as-is (which tested successfully for me), but this potentially pollutes the parent project's build directory with QuEST's build artifacts and does not seem like the cleanest solution.

Another option is to set a custom variable like QUEST_BINARY_DIR at the top level to CMAKE_CURRENT_BINARY_DIR to have a reference to QuEST's own binary dir thoughout the configure and build process, i.e. use QUEST_BINARY_DIR in CMakeLists.txt:12 to decide where to put the generated header.

I'm not too intimately familiar with cmake to know if there is a more native solution to this and what would best integrate with the existing cmake scripts, so any input on how to solve this elegantly is appreciated.

Comments

Though I'm not 100% sure, this could also be causing #689, but I have not confirmed that by trying to use FetchContent_Declare.

[otbrown]

Hi Richard, thanks for the detailed report!

I think you're quite correct that #689 and #690 are related. In #691 I've tweaked the configure step to put config.h in a more standard location and modified the build includes accordingly. Does that the fix the issue for your subdirectory build as well as FetchContent?

[rrmeister]

Thanks for the quick fix Oliver! That seems to have resolved the subdirectory problem. I'll close this Issue assuming #691 will be merged shortly.