Skip to content

Boost integration: CMake option to detect whether Capy is supported #274

@anarthal

Description

@anarthal

I'm trying to add a Capy/Corosio interface for Boost.Redis. Something like:

add_library(boost_redis_corosio INTERFACE)
target_link_libraries(boost_redis_corosio INTERFACE
  Boost::corosio
)

Adding this raw would break the Boost build, because it would unconditionally compile Capy and Corosio, which might not be supported by older compilers. To prevent this, I need to guard the library somehow:

if (SOME_CONDITION)
  add_library(boost_redis_corosio INTERFACE)
  target_link_libraries(boost_redis_corosio INTERFACE
    Boost::corosio
  )
endif()

From a conversation with @pdimov in slack, I got the following data points:

  • Checking explicitly myself is a bad idea. Patterns invoking check_cxx_source_compiles or checking CMAKE_CXX_STANDARD are error prone because it's likely that my definition of what Capy needs does not match what Capy think it needs.
  • Depending on variables set by Capy's CMake is a bad idea. Capy might not have been added to the Boost superproject when my CMake code is invoked.
  • This problem will be faced by any library depending on Capy, including Corosio, Http and Beast2. Forking Boost.Redis into Boost.Redis2 doesn't solve the problem.

Peter proposes having a BOOST_ENABLE_CAPY option in the Boost superproject, akin to the current BOOST_ENABLE_PYTHON or BOOST_ENABLE_MPI.

I've opened this issue to avoid losing this information. This is probably not relevant until Capy gets accepted into Boost.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions