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. 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?
The only other such place is Stacktrace, which wants to #error in its check
when BOOST_NO_CXX11_THREAD_LOCAL is defined, even though it already
uses thread_local itself, which would presumably fail. I understand why it's
done - Config presumably encodes knowledge of platforms where
thread_local compiles but then doesn't work - but the right thing would still
have been to make the check standalone. I was just too lazy to do it.
(*) 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.
