On 11/11/24 4:06 PM, Jeff King wrote: > The number one thing I care about as a developer is that the build is > _reliable_. Right now, if I move forwards and backwards in history and > type "make" I will almost[1] always get a correct result based on the > current tree, with the minimal required amount of building. This is > important for bisecting. > > When I have worked on other projects, especially those that use > autotools, I quite frequently run into cases where building from a dirty > state cause bizarre problems that go away with a "git clean && > ./configure && make". But then bisection is _much_ slower because we're > building from scratch (not to mention that autoconf itself is > horrifically slow). > > How does the meson build do here? I don't have any reason to think it > would be bad, but I am nervous of any change. This is something that has bothered me about autoconf as well. Meson is much more reliable about: - forcing a buildsystem reconfigure on any changes to the buildsystem files - due to using ninja, forcing any object files to be rebuilt on e.g. any changes to compiler flags, since the *entire* compiler command line is part of the key that determines staleness - keeping your existing objects between buildsystem reconfigures, if the resulting reconfigure didn't change the compiler command line for that specific object file >> Out of curiosity: did you try the Meson build? I personally have to say >> that I already prefer working with it because the workflow with it is so >> much nicer. It has nicer output, is faster, has out-of-tree builds, >> makes it easier to configure and test execution feels way nicer compared >> to my previous workflow with make. > > I hadn't tried it. I did now, checking out origin/ps/build^ (to drop the > "seen" resolution topic), but it didn't work: > > $ meson setup build > [...] > Program msgfmt found: NO > po/meson.build:3: WARNING: Gettext not found, all translation (po) targets will be ignored. > > po/meson.build:3:20: ERROR: Can not assign void to variable. > > I guess the assignment of "translations" there needs to be made > conditional? Yeah, this is an interesting quirk. Many projects would tend to figure that translation (po) targets are "optional" because if you don't have msgfmt installed then you can just install the project without any translations and then non-English speakers will be inconvenienced but at least the entire project isn't completely un-buildable. So meson automatically disables the target and logs a warning, but then this project *also* wants to depend on the translations for the testsuite. So this should be taken into account. Do the tests actually need translations, though? -- Eli Schwartz
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature
