The WSL ext4 disk I tested on was virtualized and the performance was fine. Not as good as native, I’m assuming, but not unacceptable like the FUSE/9p access to the host NTFS file system through WSL. If you’re building over 9p, I think you have bigger fish to fry.
I tried measuring glob performance in this same scenario on GitHub Actions (all virtualized) using both the Visual Studio (windows) and Ninja generators and the no-op build overhead incurred by globing was under a half second in all three scenarios.
It does seem like there are other good reasons not to glob, but I haven’t been able to reproduce the supposed performance overhead except under very silly scenarios.
Here’s an idea I had while thinking about this:
When the file list does change, CMake currently has to re-configure from scratch, whether you’re globbing or not. There is a way, I think, to get better performance than either existing approach by adding a generator expression for globs such that the result of the glob cannot be inspected during the build:
add_library(objlib OBJECT $<GLOB:src/*.cpp>)
add_executable(app1 app1/main.cpp $<TARGET_OBJECTS:objlib>)
add_executable(app2 app2/main.cpp)
target_link_libraries(app2 PRIVATE objlib)
At generation time, it is known which targets have a glob expression in their (INTERFACE_)SOURCES property and to which other targets they’re linked (or referenced by $<TARGET_OBJECTS>). So there’s enough information to incrementally update the rules that depend on the result of that glob. I guess there’s an open question here about how source file properties should apply to files matched by $<GLOB:...>, but maybe it’s okay to prohibit that because source file properties aren’t very common in user code (and you can always split up your files or refine your globs and use the target properties).
Because the result of $<GLOB:...> cannot be inspected at configure time, there’s no need to rerun the whole CMakeLists.txt when the result changes, only the generation step. That could actually save a significant amount of time. If the glob itself changes, then of course you have to re-configure.
On the other hand, this would encourage people to use globs, which I understand you don’t want 