On Mon, Nov 11, 2024 at 09:36:25PM -0500, Eli Schwartz wrote: > > - how would I know this option exists? I think you mentioned elsewhere > > in the thread the ability to ask about which options exist, but I > > couldn't find anything via "meson -h", etc. > > > meson -h lists: > > > configure Change project options > > > Which could perhaps be reworded as it allows you to both view and change > them. Ah. I saw that, but I tried: $ meson configure build Meson configurator encountered an error: ERROR: Directory /home/peff/compile/git/build is neither a Meson build directory nor a project source directory. which seemed like a chicken-and-egg (I cannot configure a build directory until I "setup", but I cannot "setup" until I figure out the configuration options that work). But it seems: $ meson configure . gives me a list, albeit with a warning about using the source directory. It looks like just "meson configure" does the same, but somehow I didn't try that. ;) > > - is there a way to put configuration like this in a file, similar to > > our current config.mak? > > https://mesonbuild.com/Machine-files.html > > machine files (passed via --cross-file or --native-file) allow you to > define your toolchain, e.g. set up persistent CFLAGS and CC that you can > store as a configuration file, check into git, share with people, etc. Thanks. And sorry, I am being a bit more lazy than usual about going out and reading documentation on my own[1]. My usual workflow is to symlink config.mak to my custom file (which of course I maintain in another Git repo). And then "make" just does the right thing, even if I'm moving around through history, bisecting, etc. I think the meson equivalent is that I would "meson setup build --native-file /path/to/my/config.mak" once, which would copy all of the values in to that environment. And then starting ninja from that "build" directory would presumably work throughout history. My config.mak does have some runtime logic, though (e.g., when bisecting old commits it relaxes the compiler options). It sounds like that would need to re-run meson, and not work at the ninja level. I'm also not clear on how to alternatively build with different optimization levels, or with different sanitizers. Right now that is: # normal build and test some script make && cd t && ./t0000-basic.sh -v -i # now with sanitizer make SANITIZE=address && cd t && ./t0000-basic.sh -v -i If I understand correctly, the workflow here is either to have two separate build directories, or to "meson configure" between the two. And AFAICT the tests _have_ to be run via "meson test" now, if we want them to find the Git built in the separate directories. -Peff [1] I think my gut feeling is that these are questions that Patrick should be answering if he wants to sell the project on moving away from make. I know we can't expect to be spoon-fed all parts of a transition, but I am starting from the point of view of: I am perfectly happy with make, why do you want me to switch? Another thing I am observing about this is that "meson" is not really just replacing "make". It is also replacing autoconf to some degree in probing various things (like gettext). But that is not something I (or most developers) were using at all. So it is not just transitioning to a different piece of software, but also changing the fundamental approach. Though I imagine with the right --native-file options, I could disable all of the probing entirely.
