On Tue, Dec 20 2022, Junio C Hamano wrote: > Phillip Wood <phillip.wood123@xxxxxxxxx> writes: > >> On 19/12/2022 10:26, Ævar Arnfjörð Bjarmason wrote: >>> In [1] I made the same change to our Makefile, let's follow-up and do >>> the same here. >>> For "cmake" this is particularly nice with "-G Ninja", as before >>> we'd >>> emit ~40 lines of overflowed progress bar output, but now it's only >>> the one line of "ninja"'s progress bar. >> >> I don't really have a strong opinion either way on this but if it >> matches what we do in the Makefile than it sounds sensible. > > As a one-shot change, it might be sensible to claim consistency by > saying "we do the same thing in two places", but I'd worry more > about the root cause of such inconsistency in the first place, i.e. > can we have some trick to ensure that two build systems will not > reimplement the same thing slightly differently? We could & should, but I think doing prep changes like these first makes sense, as eventually e.g. driving both the Makefile & CMake via some shared resource won't have to waste time on explaining why the msgfmt invocation is slightly different. > It also is worth examining if having "the same change" is a good > idea in the first place. The justification given "In [1]" was that > a build driven by our Makefile were concise and non-verbose overall, > but with --stat that concise output pattern was broken. > > I do not know (and I do not have particular interest in knowing) how > a build driven by cmake looks like, but does it also aim the same > concise output where output --stat does not fit well, ... It's the same with CMake, as e.g. the reference to "ninja" in the commit message covers (it would also happen with the "make" backend, but that one's a bit more verbose by default). > [...] or do folks who daily build with cmake find the output with > --stat sit well in the output from other things given there? If the > latter, making "the same change" as the Makefile side may not make > much sense. I think the only justification that's needed here (and which should short-circuit any questions about what someone using cmake may or may not like) is the one given in my 2f12b31b746 (Makefile: don't invoke msgfmt with --statistics, 2021-12-17). I.e. this was something I added as part of the initial i18n support, but I had no good reason for using --statistics other than ad-hoc eyeballing the output at the time. The CMake recipe then just copy/pasted whatever it found in the Makefile, and the two then drifted apart. So, in general with those sorts of changes I think it's sufficient to say that we're not bringing them in line again, unless there's some reason to suppose that the cmake version has since come to rely on the divergence for some reason. Which, in this case is clearly not the case, as we're just spewing this output to the user's terminal.
