CMake examples contain bad example for including conanbuildinfo.cmake

[sigiesec]

Most (?) CMake examples suggest to include the conanbuildinfo.cmake file as follows:

include(${CMAKE_BINARY_DIR}/conanbuildinfo.cmake)

However, this is incompatible with using conan workspaces. CMAKE_CURRENT_BINARY_DIR should be used instead (as in the conan workspaces example repository).

[memsharded]

I think I recall using CMAKE_CURRENT_BINARY_DIR to have a different problem, for normal packages (not workspaces), if the CMakeLists.txt including the conan functionality is in a subfolder, then it will fail, as the typical flow (and what most users find rasonable) is to generate the conanbuildinfo.cmake in the root of the build directory (CMAKE_BINARY_DIR), irrespective of where the calling CMakeLists.txt is.

We need to investigate this further, and make sure about this, I think.

[sigiesec]

Hm, that would certainly be a problem.

There is no such thing as a workspaces package, this is not a property of a package, but a mode of using it.

Ideally, any package should be usable in a workspace, but this is hard to ensure. But at least a package that can be used in workspace mode must also be usable in "normal" mode. And the conan examples should allow for this, or at least explicitly mention that certain constructs are in conflict with workspace mode.

What you wrote above, should be mentioned in the docs, e.g. Since a toplevel CMakeLists.txt file with the regular "cmake" conan generator will depend on conan anyway, it should be acceptable to place it under conan conventions if necessary.