Cmake glob pattern7/29/2023 ![]() On the other hand, this would encourage people to use globs, which I understand you don’t wantĪs a Symfony developer, it's always been hard to get a st … able/fast development environment. If the glob itself changes, then of course you have to re-configure. That could actually save a significant amount of time. 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).īecause 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. So there’s enough information to incrementally update the rules that depend on the result of that glob. Target_link_libraries(app2 PRIVATE objlib)Īt 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 $). 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 $) ![]() When the file list does change, CMake currently has to re-configure from scratch, whether you’re globbing or not. Here’s an idea I had while thinking about this: 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. 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. If you’re building over 9p, I think you have bigger fish to fry. Not as good as native, I’m assuming, but not unacceptable like the FUSE/9p access to the host NTFS file system through WSL. The WSL ext4 disk I tested on was virtualized and the performance was fine. Running this same experiment from Windows on a SATA SSD (SanDisk SDSSDHII480G) formatted with NTFS gives 0.116s, so SATA versus NVMe performance seems dominated by NTFS overhead.ĭon’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). Running this same experiment from Windows on the exact same NTFS drive gives 0.119s, so NTFS is a good bit slower than ext4. Running this same experiment from WSL on the NTFS part of the same drive crashes performance to 2.373s, but this is probably just WSL’s poor filesystem performance generally. usr/bin/cmake -P /home/alex/test/build/CMakeFiles/VerifyGlobs.cmake $ cat CMakeLists.txtįile(GLOB sources CONFIGURE_DEPENDS "src/*.cpp") I get 0.019s for a no-op build on WSL on the virtual ext4 disk, in a Samsung 970 EVO 1TB. I’m curious what your numbers are on this test case (directory with 1000 sources).
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |