# Is GLOB still considered harmful with CONFIGURE\_DEPENDS?
**URL:** https://discourse.cmake.org/t/is-glob-still-considered-harmful-with-configure-depends/808
**Category:** Code
**Created:** [March 17, 2020, 10:28am UTC](https://discourse.cmake.org/t/is-glob-still-considered-harmful-with-configure-depends/808 "2020-03-17T10:28:35Z")
**Posts on this page:** 1
**Showing post:** 15
### Author:  [@alex](https://discourse.cmake.org/u/alex)
#### Post date: [June 5, 2021, 1:34am UTC](https://discourse.cmake.org/t/is-glob-still-considered-harmful-with-configure-depends/808/15 "2021-06-05T01:34:42Z")
> [@craig.scott](#):
>
> Don’t forget that people also build in VMs with virtualised disks, the performance of which could vary considerably (sometimes due to technical limitations, sometimes due to expertise limitations of the person who sets them up).
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:
```auto
add_library(objlib OBJECT $)
add_executable(app1 app1/main.cpp $)
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 `$`). 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 `$`, 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 `$` 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 🙂
---
_[View the full topic](https://discourse.cmake.org/t/is-glob-still-considered-harmful-with-configure-depends/808)._