Re: [cmake] Problem with dependencies for configure checks

From: Peter Dimov (pdimov_at_[hidden])
Date: 2021-06-04 00:29:06

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.