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