On Tue, 11 Feb 2025 15:42:11 +0100 ichthyo <p...@ichthyostega.de> wrote:
>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 This is far more complex than I realised :( A number of people have modified Yoshimi's CMake list since Paul's Zyn. original. Initially Cal replaced all the individual ones with a single file, then other changes were made later. I confess, that with any additions I've made, I simply followed what I could see of the existing entries, as well as adding some advisories and policy changes that were flagged. -- Will J Godfrey _______________________________________________ Yoshimi-devel mailing list Yoshimi-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/yoshimi-devel
