[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]

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

I the header sources may be used with many other LSPs like clangd, or (God knows, but just thinking along) some AI coding agents (?). I, for example use a clangd LSP (YouCompleteMe) in Vim that picks up the context from CMake.

It's not entirely clear whether you want to suppress header globbing or simply replace it with explicit lists. The latter should be no problem for anyone, but removing it might have more impact than the quoted claim appears to suggest.

[cdglove]

My preference is to explicitly list headers in the build files. I merely did it this way because that's what every other library currently does.

See my corresponding post on the mailing list:
https://lists.boost.org/archives/list/boost@lists.boost.org/thread/LKPFNC3AMPIVWRAE75EFMYRMS6AL6MV4/

The other tools you mention don't typically pick up headers from generated build files but from the build targets (often output to compile_command.json). There might be a use case I'm not aware of, but I doubt that's why these were added in the first place since a correct build doesn't depend on them.

[sehe]

The post on the mailing list is how I knew about these PRs (thank you for that).

I'm pretty satisfied with the observation that other libraries already do it this way. That at least means no-one ran into active problems there, so that's good.

I can think of one use-case: running run-clang-tidy from the CMake setup might not pick up headers to lint. I don't currently have clang-tidy integrated in my dev environment, so I cannot readily test it. It's not a high priority use case, in general I think, as it is pretty easy to add the globs to the invocation itself.

[cdglove]

Good point about clang-tidy. As far as I'm aware, --header-filter=* will glob your headers for clang-tidy, but to me that's still inferior to listing the headers explicitly and avoiding GLOB entirely. I'm curious what others on the list think and would be fine abandoning these changes in favour of a bigger fix if that's the decision.

[nigels-com]

I'm happy if this style of fix solves the problem at hand.
But I do think cmake globbing is best avoided for production software.
One strong argument is build determinism, the binary should be bitwise unchanged, for the same input/config.

There is some good information here:
https://reproducible-builds.org/docs/deterministic-build-systems/