在CMake中如何指定库包含的方法并检测编译配置以适配下游依赖目标？

Great question! When dealing with CMake projects where library features are controlled by build options, the most reliable approach is to explicitly pass the configuration state downstream rather than trying to reverse-engineer it from the compiled library. Here are your options, ordered by recommendation:

1. Pass Build Configuration to Downstream Projects (Recommended) #

CMake is designed to handle this scenario cleanly by letting you export build-time configuration details to dependent targets. Here's how to implement it:

Step 1: Export the ADD_BAR Option in Your Library's CMakeLists.txt #

First, ensure your library makes its build configuration visible to downstream projects. You can do this via compile definitions and generated config headers:

# foo/CMakeLists.txt
option(ADD_BAR "Include the bar methods" ON)

# Generate a config header to expose ADD_BAR to code (optional but useful)
configure_file(foo_config.h.in foo_config.h @ONLY)

add_library(foo SHARED foo.cpp)

# Make the generated config header available to downstream targets
target_include_directories(foo PUBLIC 
  ${CMAKE_CURRENT_SOURCE_DIR}
  ${CMAKE_CURRENT_BINARY_DIR}
)

# Export ADD_BAR as a PUBLIC compile definition so downstream targets inherit it
target_compile_definitions(foo PUBLIC 
  $<$<BOOL:${ADD_BAR}>:ADD_BAR>
)

# Optional: If your library is installed/found via find_package, export the option
include(CMakePackageConfigHelpers)
write_basic_package_version_file(
  fooConfigVersion.cmake
  VERSION 1.0.0
  COMPATIBILITY AnyNewerVersion
)
configure_package_config_file(
  fooConfig.cmake.in
  ${CMAKE_CURRENT_BINARY_DIR}/fooConfig.cmake
  INSTALL_DESTINATION lib/cmake/foo
)
install(TARGETS foo EXPORT fooTargets DESTINATION lib)
install(EXPORT fooTargets FILE fooTargets.cmake DESTINATION lib/cmake/foo)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/fooConfig.cmake ${CMAKE_CURRENT_BINARY_DIR}/fooConfigVersion.cmake DESTINATION lib/cmake/foo)
install(FILES ${CMAKE_CURRENT_BINARY_DIR}/foo_config.h DESTINATION include)

The foo_config.h.in would look like this:

// foo_config.h.in
#pragma once
#cmakedefine ADD_BAR

Step 2: Check the Configuration in Downstream Projects #

Once your library exports the ADD_BAR definition, downstream projects can directly use it to skip targets that depend on the bar() function:

# downstream/CMakeLists.txt
find_package(foo REQUIRED)

# Skip bar-dependent targets if ADD_BAR is disabled
if(NOT ADD_BAR)
  message(STATUS "ADD_BAR is disabled in libfoo.so; skipping bar-dependent targets")
  # Either return early or skip specific targets
  return()
endif()

# Target that depends on bar()
add_executable(bar_consumer bar_consumer.cpp)
target_link_libraries(bar_consumer PRIVATE foo)

This approach is cross-platform, reliable, and aligns with CMake's intended workflow for dependency management.

2. Detect Symbols in the Compiled Library (Not Recommended) #

If you absolutely need to detect the presence of bar() in the compiled library (e.g., if you can't modify the library's CMake setup), you can use platform-specific tools like nm (Linux/macOS) or dumpbin (Windows) to check for the symbol. However, this is fragile due to platform differences, symbol mangling, and potential optimizations that remove unused symbols.

Here's an example for Linux/macOS:

# downstream/CMakeLists.txt
find_library(FOO_LIBRARY foo PATHS ${FOO_INSTALL_DIR}/lib)

execute_process(
  COMMAND nm -D ${FOO_LIBRARY}
  OUTPUT_VARIABLE FOO_SYMBOLS
  RESULT_VARIABLE NM_EXIT_CODE
)

if(NM_EXIT_CODE EQUAL 0)
  string(FIND "${FOO_SYMBOLS}" "bar" BAR_SYMBOL_FOUND)
  if(BAR_SYMBOL_FOUND GREATER_EQUAL 0)
    set(HAVE_BAR_FUNCTION TRUE)
  else()
    set(HAVE_BAR_FUNCTION FALSE)
  endif()
else()
  message(WARNING "Failed to run nm on libfoo.so; assuming bar() is not present")
  set(HAVE_BAR_FUNCTION FALSE)
endif()

if(NOT HAVE_BAR_FUNCTION)
  message(STATUS "bar() not found in libfoo.so; skipping dependent targets")
  return()
endif()

# Proceed with bar-dependent targets...

For Windows, you'd replace nm -D with dumpbin /exports ${FOO_LIBRARY} and adjust the string matching logic.

Key Takeaway #

Always prefer explicit configuration passing (Option 1) over symbol detection. It's cleaner, more maintainable, and avoids the pitfalls of platform-specific symbol checking.

内容的提问来源于stack exchange，提问作者vitalstatistix