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

1. 
   maflcko commented at 12:35 pm on September 2, 2024: member

   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?
2. maflcko added the label Build system on Sep 2, 2024
3. maflcko added the label Questions and Help on Sep 2, 2024
4. 
   hebasto commented at 12:42 pm on September 2, 2024: member

   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.
5. 
   fanquake commented at 12:47 pm on September 2, 2024: member

   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.
6. 
   maflcko commented at 12:53 pm on September 2, 2024: member

   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?

7. fanquake removed the label Questions and Help on Sep 2, 2024
8. 
   fanquake commented at 12:57 pm on September 2, 2024: member

   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?

9. 
   maflcko commented at 1:11 pm on September 2, 2024: member

   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.

10. 
    fanquake commented at 1:27 pm on September 2, 2024: member

    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?

11. fanquake referenced this in commit dda17b44e7 on Sep 5, 2024
12. fanquake referenced this in commit a7a4e11db8 on Sep 5, 2024
13. fanquake closed this on Sep 6, 2024

    ---

14. fanquake referenced this in commit c3af4b1ec3 on Sep 6, 2024

Contributors
maflcko hebasto fanquake

Labels
Build system