These properties are only named with INTERFACE_ so they are whitelisted for interface libraries. Instead there should be a corresponding bcm_target_ function to set the property.

You save the need to specify one thing to link against, but you introduce an implicit target dependency. I think this feature should be removed.

Instead a ignore_package function can be provided:

function(ignore_package NAME)
    file(WRITE ${CMAKE_BINARY_DIR}/${NAME}/${NAME}Config.cmake "")
    set(${NAME}_DIR ${CMAKE_BINARY_DIR}/${NAME} CACHE PATH "")
endfunction()

This is much better than suggesting to use undocumented override.

For example, I want to be able to check that a specific error message is emitted (a static_assert, say). The way I do that right now is by putting the following in the source file:

// in foo.cpp
int main() {
  // MESSAGE[Incomplete definition of your concept map]
  auto const& map = dyno::complete_concept_map<Fooable, int>(dyno::concept_map<Fooable, int>);
}

I then create a compile_fail test for foo.cpp and that checks whether there's an expected message. See https://github.com/ldionne/dyno/blob/master/cmake/CompileFailTest.cmake for an implementation.

I'd like to incorporate bcm into our build system. Since there is no license file present in the repository I was wondering if you could add one.

Thank you :)

This would be the most appropriate place for compatibility.

I'm failing to install BCM. I'm assuming that it is an issue at my side but I'v followed the documentation exactly and I was thinking that maybe there are some prerequisites I missed; which could be part of the documentation to help with resolving issues like mine.

• I'v cloned the repo next to my other repos.
• Then, in the bcm repo, I did:
  mkdir build
  cd build
  cmake ..
  cmake --build . --target install
• Then, in the CMakeLists.txt of my own project, tried to use;
  find_package(BCM)
  include(BCMDeploy)
  bcm_deploy(TARGETS config INCLUDE include)

For me find_package(BCM) failes with:

-- Could NOT find BCM (missing: BCM_DIR)
CMake Error at pi_core/pi_tracing/CMakeLists.txt:4 (include):
include could not find load file:

BCMDeploy

CMake Error at pi_core/pi_tracing/CMakeLists.txt:5 (include):
include could not find load file:

BCMSetupVersion

CMake Error at pi_core/pi_tracing/CMakeLists.txt:7 (bcm_setup_version):
Unknown CMake command "bcm_setup_version".

-- Configuring incomplete, errors occurred!

This would be similar to the <warnings> feature in Boost.Build, which allows:

• off - disables all warnings.
• on - enables default warning level for the tool.
• all - enables all warnings.

See features.

The convention in CMake is to have target properties that are initialized with the value of an associated CMAKE_<property> variable.

See this comment from @eldiener:

Why not have the line:

add_library(${PARSE_NAME} STATIC EXCLUDE_FROM_ALL ${SOURCES})

be instead:

add_library(${PARSE_NAME} OBJECT EXCLUDE_FROM_ALL ${SOURCES})

if it works. This would allow just the creation of object files rather than the creation of a static library, which is overkill in this situation.

And add a bcm_add_test_subdirectory function that will add the test directory if the ENABLE_TESTS directory property is enabled. This should help deal with the issue here.

Something like:

set_target_properties(${EXPORT_TARGETS} PROPERTIES
  DEBUG_POSTFIX "-d"
  SO_VERSION ${EXPORT_VERSION}
  VERSION ${EXPORT_VERSION}
  )

install(TARGETS ${EXPORT_TARGETS} EXPORT ${EXPORT_SET}
  ARCHIVE
    DESTINATION "${CMAKE_INSTALL_LIBDIR}"
    COMPONENT ${EXPORT_COMPONENT}_DEV
  LIBRARY NAMELINK_ONLY
    DESTINATION "${CMAKE_INSTALL_LIBDIR}"
    COMPONENT ${EXPORT_COMPONENT}_DEV
  LIBRARY CONFIGURATIONS Debug NAMELINK_SKIP
    DESTINATION "${CMAKE_INSTALL_LIBDIR}"
    COMPONENT ${EXPORT_COMPONENT}_DBG
  LIBRARY CONFIGURATIONS Release NAMELINK_SKIP
    DESTINATION "${CMAKE_INSTALL_LIBDIR}"
    COMPONENT ${EXPORT_COMPONENT}
  RUNTIME
    DESTINATION "${CMAKE_INSTALL_BINDIR}"
    COMPONENT ${EXPORT_COMPONENT}
  INCLUDES
    DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}"
  )

This can help with integrated builds to disable installation of dependencies. When set to off, bcm_install_targets will be a no-op. This can probably even be a target-level property.

It seems like a bad idea to allow setting anything global. I thought modern CMake was all about explicitly stating what your dependencies are when creating a target. Unless there's a good reason to have this, I would rather not have it at all, because I think I would always consider this an anti-pattern.

Since you have support in for COMPILE_ONLY in the bcm_test for paralleling the compile/compile-fail rules of Boost Build you can also add support for Boost Build link/link-fail rules with a LINK_ONLY option. You would implement this like the COMPILE_ONLY but in this case your target would be an executable with an EXCLUDE_FROM_ALL and your test would simply be an attempt to build the executable. If you like you could call this option BUILD_ONLY instead of LINK_ONLY, although the LINK_ONLY better mirrors the Boost Build rule name. Once this is done you would have covered the specializing testing rules of Boost Build explained at http://www.boost.org/build/doc/html/bbv2/builtins/testing.html.

This is needed by boost.spirit examples.