Re: [cmake] Problem with dependencies for configure checks

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-06-03 16:02:18

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/79aff77771a8f3a3d62852de6619a955fd4c2634/CMakeLists.txt#L75

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 <C:/boost-dir/libs/filesystem/config/ has_stat_st_blksize.cpp>
> 
> which the Cygwin compiler doesn't like and the test always fails. So I've had to use
> 
> https://github.com/boostorg/stacktrace/blob/79aff77771a8f3a3d62852de6619a955fd4c2634/CMakeLists.txt#L59
> 
> instead.

I'm not sure I understand. Is it that Cygwin doesn't accept angle 
brackets with Windows paths?