On 6/3/21 6:43 PM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
Hi,
I've been having this problem with CMake in Boost.Filesystem, where I need to have the Boost::library targets available before Boost::filesystem target is defined. This is needed in order to perform configuration checks that will affect how Boost::filesystem will be defined. For example, see the check_cxx_source_compiles calls:
https://github.com/boostorg/filesystem/blob/af6ac28b5785820b93a2af7dd6 e9b801232fec19/CMakeLists.txt#L23-L50
For the check_cxx_source_compiles calls, I would have liked to add targets like Boost::config and Boost::winapi to CMAKE_REQUIRED_LIBRARIES so that the checks are compiled with include directories of those dependencies added in the command line. This doesn't work because these targets may not be defined at the point when the configuration checks are performed.
My current workaround, as you can see, is to add the Boost root to CMAKE_REQUIRED_INCLUDES, where the boost directory with the common headers tree is located. However, this will not work if we're going to make that directory optional or remove it. Also, you can see that I'm reusing checks implemented in Boost.Config, for which I also had to hard code its relative location from Boost.Filesystem. If we're going to allow different libraries located in separate directory trees, this will also break.
My question is, can this be fixed and how?
I add ../config/include to CMAKE_REQUIRED_INCLUDES.
https://github.com/boostorg/stacktrace/blob/79aff77771a8f3a3d62852de6619a955...
But that would mean one has to specify second order dependencies as well for configure checks. This might be fine for Boost.Config, but not for other libraries that have dependencies. Boost.WinAPI is an example; I wouldn't want to replicate its dependencies in all downstream libraries that have checks involving it.
I don't think we should mandate add_subdirectory calls to come in a specific order. Even if we can hack something in the superproject to do it, users who use add_subdirectory manually will need to get the order right.
Incidentally,
#include <${CMAKE_CURRENT_SOURCE_DIR}/config/has_stat_st_blksize.cpp>
doesn't work on Cygwin with the Windows CMake; this ends up generating
#include
which the Cygwin compiler doesn't like and the test always fails. So I've had to use
https://github.com/boostorg/stacktrace/blob/79aff77771a8f3a3d62852de6619a955...
instead.
I'm not sure I understand. Is it that Cygwin doesn't accept angle brackets with Windows paths?