[cdglove]

When file(GLOB ... CONFIGURE_DEPENDS) or file(GLOB_RECURSE ... CONFIGURE_DEPENDS) is evaluated, CMake's make style generators create a verification script (VerifyGlobs.cmake) that gets run on every build, outputting "Re-checking globbed directories....". This can cause a a noticeable delay on incremental builds.

Since the headers are only needed for IDE project navigation, limiting this check to that use case is a good compromise.

[sehe]

I asked a question about the validity of the reasoning here boostorg/assert#49 (comment)

[gennaroprota]

Thanks for the PR.

In this library, though, the glob does nothing on any generator. BOOST_STATIC_STRING_HEADERS is only passed to source_group, and no target lists those files (boost_static_string is an INTERFACE library with no sources). So the headers don't show up in the IDE, Visual Studio included: I generated a VS 2022 solution and no .vcxproj or .filters file mentions them. Visual Studio still runs the check on every build through ZERO_CHECK, so with this change VS users keep paying for nothing. (BOOST_STATIC_STRING_SOURCES is never defined either; there's no src/ directory.)

For the same reason, sehe's concern about clangd and clang-tidy doesn't apply here: compile_commands.json and the CMake file API output are identical with and without this change, and neither lists the library's headers.

Also, moving set_property(GLOBAL PROPERTY USE_FOLDERS ON) inside the condition turns folders off for Xcode, and it's a global property, so that reaches other libraries in a superproject build.

Could you instead remove the file(GLOB_RECURSE ...) and both source_group calls, and leave USE_FOLDERS unconditional? That gets rid of the check on every generator without changing anything users can see.

[cdglove]

Oh good catch! Submitted a few other PRs in other libraries so I'll double check those.

Could you instead remove the file(GLOB_RECURSE ...) and both source_group calls, and leave USE_FOLDERS unconditional?

Yes. Thank you for testing it.