From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2021-06-04 00:47:09
On 6/4/21 3:29 AM, Peter Dimov via Boost wrote:
> Andrey Semashev wrote:
>>> Why would every library need to do it? Why would it need to glob? I've
>>> done most of them by now and not one of them needs to do so.
>>
>> Probably because most of them don't do configure checks or don't use Boost
>> while doing so. In the cases I mentioned, I do use Boost for configure time
>> checks, and globbing is a way to avoid having to hardcode the dependency
>> tree for those checks.
>
> I don't think globbing would be a particularly good practice in this case, but
> whatever floats your boat, I suppose.
Sure, I don't like it either. That's why I asked if something better
could be done in Boost.CMake, or however it is called.
> I will continue hardcoding the required
> include directories. That's not that great a practice either (*), but I don't see
> anything better.
>
> Why is that even necessary? Configure checks should be standalone. There's
> no problem using <windows.h> there instead of insisting on winapi, is there?
In the particular case of Boost.WinAPI I want it (Boost.WinAPI) to
define all the version macros it defines. This way I ensure that the
config check is compiling in the same environment as the library will. I
actually include a special header from Boost.Filesystem
(platform_config.hpp) to define all platform-specific macros, which
indirectly includes Boost.Config and Boost.WinAPI.
In Boost.Log I have a config check that uses Boost.Atomic to test if it
supports the required lock-free operations on a given target platform.
> (*) It will fail when dependencies are pulled at configure time by
> FetchContent or package manager integration. E.g.
>
> pacman_add_subdir(boost_this boost/this)
> pacman_add_subdir(boost_that boost/that)
> pacman_add_subdir(boost_other boost/other)
>
> If boost_this wants boost_other, it won't find it, because it hasn't been
> downloaded yet. It will find it on the second configure run, but the checks
> would have been cached then, and will not run.
I'm inclined to simply not support incomplete source trees.