Boost logo

Boost :

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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk