On 10.02.25 10:19, Will Godfrey wrote:
While reading up on this a bit, I noticed that using globbing is rather contentious, and mostly discouraged.
Hi Yoshimi-devs, Globbing in the context of build systems in general tends to be a topic which attracts strong opinions and has a tendency to spur passionate discussions. In fact it is a matter of perspective -- or shall I say, "mental model". - some people conceptualise the act of building as /compiling individual/ translation units. Those people tend to reject globbing. - other people understand building as processing a /source tree/ -- those tend to embrace globbing. According to my personal experience, people in the "single files" camp often favour having several versions of the same file in tree and decide which one to use and also like setting different build flags for individual files. While people in the "source tree" camp often like refactoring and moving around code a lot in deep structured trees and are thus hampered by the need to maintain source lists manually. This is the general part. Now there is that amazing thing called CMake. I must admit that I don't understand what's the matter with CMake, but there was a stunning tendency towards oversimplification right from start, and they even seem to be proud of smashingly simplified solutions and superficially clever tricks, where any halfway experienced developer can spot in 5 seconds that there will be problems down the road. So for example like treating library dependencies as a simple text substitution. Which is the root of the problems at hand (a library dependency is a structured information, comprised of binary locations, include paths, and additional flags to pass to several build steps). And the same was true for globbing. They did not seem to get the obvious fact that globing can detect new files, prompting a need to reconfigure the build. Which somehow was against their "principles". So the globbing implementation of CMake was broken for an endless time span, and people got bitten numerous times. Needless to say, this was lustfully pointed out by the "anti-globbing" fraction of the developer population. With CMake 3.12, this bug was *fixed*, finally. However, there is a special option, which needs to be set in order to get the correct behaviour, which is to perform a tree scan on each build and re-trigger project configuration when a real change is spotted. Correct globbing has a run time cost, which is in the order 1/10 sec on a decent file system, but can take up to 2 seconds on some "special" MS windows boxes. And, of course, if you have millions of files in the source tree, that's a different story.
We use this for building the LV2 code, so I'm wondering if we should change it
Indeed, we are using the GLOB statement in a way that does not make any sense, because it is followed by an explicit and manually maintained list of files. And we don't use the flag for proper globbing, so we also would get the broken old CMake behaviour (which does not matter in our case, because we're actually not /globbing/ at all). Please have a look at the Testrunner, where I tried to use the more modern way right from start. This also shows an example for library deps: - use the pkg_check_modules with the IMPORTED_TARGET (important!) - refer to the dependency as PkgConfig::SNDFILE (in this example) - use recursive globbing on the whole tree, with a real glob "src/*.cpp" - and set the flag CONFIGURE_DEPENDS to trigger re-configuration on change https://github.com/Ichthyostega/yoshimi-test/blob/master/yoshimi-testrunner/CMakeLists.txt Here is the CMake Documentation for globbing: https://cmake.org/cmake/help/latest/command/file.html#glob -- Hermann _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
