Strange issue with variables in a config-file cmake package

Question

We can use a cmake config file to import targets. For example given machinary including foobarConfig.cmake.in

set(FOOBAR_VERSION @VERSION@)

@PACKAG         


        

Answer 1

check_required_components(Foobar) should be called at the end in the case. The docs.

check_required_components() should be called at the end of the FooConfig.cmake file. This macro checks whether all requested, non-optional components have been found, and if this is not the case, sets the Foo_FOUND variable to FALSE, so that the package is considered to be not found. It does that by testing the Foo__FOUND variables for all requested required components. This macro should be called even if the package doesn’t provide any components to make sure users are not specifying components erroneously. When using the NO_CHECK_REQUIRED_COMPONENTS_MACRO option, this macro is not generated into the FooConfig.cmake file.

Answer 2

Oops. This is embarrassing. I'd moved the generation code into a shell script and forgot to escape the variables!

cat - >CMakeLists.txt <<EOF
cmake_minimum_required(VERSION 3.7)
project(useFoo VERSION 1.2.3)

find_package(FoobarLib ${MIN_FOOBARLIB_VERSION}
  HINTS "${WSDIR}/opt/foo"
  PATHS /opt/foo
  REQUIRED)

message(STATUS "Foobar library version: ${FOOBARLIB_VERSION}")
message(STATUS "Foobar library location: ${FOOBARLIB_LIB_DIR}")


message(STATUS "FoobarLib_FOUND=${FoobarLib_FOUND}")
message(STATUS "FoobarLib_PATH=${FOOBARLIB_PATH}")
message(STATUS "FoobarLib_DIR=${FoobarLib_DIR}")

message(STATUS "FOOBARLIB_FOUND=${FoobarLib_FOUND}")
message(STATUS "FOOBARLIB_PATH=${FOOBARLIB_PATH}")
message(STATUS "FOOBARLIB_DIR=${FoobarLib_DIR}")

file(GENERATE OUTPUT foobar-loc CONTENT "<TARGET_FILE:foobar>=$<TARGET_FILE:foobar>\n")

EOF

The question is still useful for providing source for the related question though.

To answer my own questions:

How can I find this problem? Avoid similar problems in the future? Create these files in a safe and canonical way?

• https://en.wikipedia.org/wiki/Rubber_duck_debugging
• Reduce the problem to a minimum reproducible example (preferably before posting on stack overflow)
• Avoid (or at least take extra care) generating code from shell scripts
• Reduce stress and get more sleep