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
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.