cmake: Step "-- Looking for C++ include boost/test/included/unit_test.hpp" takes a long time #30787

It looks like this step is taking longer than the entire cmake -B without it. Is there a reason why it takes so long, and whether it can be sped up?

It compiles and links the minimal code that uses the boost/test/included/unit_test.hpp header. Verifying that the header simply exists could be an alternative.

It's actually irrelevant for all platforms other than windows with vcpkg (as far as I'm aware), and was added to work around how boost is packaged there (we didn't have an equivalent in autotools). It should be scooped as such, rather than making all other platforms run the (pointless) slow check.

Verifying that the header simply exists could be an alternative.

Yeah, that seems ideal, given that this was done for autotools as well, assuming it also works with vcpkg?

It compiles and links the minimal code that uses the boost/test/included/unit_test.hpp header.

I am using ccache to compile, but I guess this won't be picked up here?

Yeah, that seems ideal, given that this was done for autotools as well,

Where in Autotools were we running checks to verify the existence of singlular boost headers at configure time?

Where in Autotools were we running checks to verify the existence of singlular boost headers at configure time?

I haven't confirmed this, but I assumed it checked for boost/version.hpp existence (and version conformance). Though, maybe I am wrong. In any case, anything is fine by me. I just found that it would be nice if calling rm -rf ./bld-cmake/ && cmake -B ./bld-cmake was fast, so all developers can just call it every time, without having to think about it much.

I haven't confirmed this, but I assumed it checked for boost/version.hpp existence (and version conformance).

We did do a high-level check for the existence of a Boost installation, and sufficient version (and that is what is also done in CMake now), but not compilation checks for individual headers (otherwise we should add checks for all Boost headers that we might happen to #include, i.e boost/multi_index/*, if we think they might be missing for some reason).

I think either making this faster, i.e no compilation, or scoping it to vcpkg is fine.

It compiles and links

Should it be doing anything link related, if our Boost usage is header only?