Re: [PATCH v8 00/17] Upstreaming the Scalar command
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Nov 23, 2021, 12:45 UTC
- Message-ID
- <211123.86ee77uj18.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <nycvar.QRO.7.76.6.2111231249080.63@tvgsbejvaqbjf.bet>
On Tue, Nov 23 2021, Johannes Schindelin wrote:
Show 36 quoted lines
> Hi Ævar, > > On Tue, 23 Nov 2021, Ævar Arnfjörð Bjarmason wrote: > >> [...] >> $ make clean; make -C contrib/scalar test >> [...] >> CC hook.o >> CC version.o >> CC help.o >> AR libgit.a >> make[1]: Leaving directory '/home/avar/g/git' >> SUBDIR ../.. >> make[1]: Entering directory '/home/avar/g/git' >> * new link flags >> CC contrib/scalar/scalar.o >> LINK contrib/scalar/scalar >> make[1]: Leaving directory '/home/avar/g/git' >> make -C t >> make[1]: Entering directory '/home/avar/g/git/contrib/scalar/t' >> *** prove *** >> error: GIT-BUILD-OPTIONS missing (has Git been built?). >> t9099-scalar.sh .. Dubious, test returned 1 (wstat 256, 0x100) >> No subtests run > > That's cute. You seem to have missed that this is `contrib/`? The > assumption of pretty much _everything_ in there is that Git was already > built. > > Try this at home: `make clean && make -C contrib/subtree/ test` > > Yep. It "fails" in the same way. "has Git been built?". > > So if that was all the evidence in favor of that misinformation "Scalar's > build is broken! Broken, broken, BROKEN!", I think we can now let it rest. > At last.
No, it doesn't fail in the same way. Really, it seems like you're either not fully reading through E-Mails before replying, or entirely misunderstanding what I'm saying. I highlighted the difference in "[...]that's not broken because[...]" below the context you're quoting.
I'm specifically pointing out the difference between how these act:
make clean; make -C contrib/subtree/ test
make clean; make -C tWhich fail right away without trying to build anything, and how your:
make clean; make -C contrib/scalar test
Won't fail right away, but get most of the way towards building what it needs at the top-level.
So yes, I fully agree with your contrib/subtree example, but it's making my argument for me.
As I pointed out in the just-sent [1] the main issue is that your latest iteration added "make -C contrib/subtree/ test" in the wrong place, and we thus ended up running those tests in places we didn't intend. The main conflict is that semantic conflict.
But that failure also highlighted that contrib/scalar/Makefile will run a build of the top-level C code, only to error out with "GIT-BUILD-OPTIONS".
That specifically is what I consider broken. It should either actually work and properly build its dependency, or not even try.
Either one would be fine in this context, it's the in-between that's clearly (to me at least) broken. Working software should either attempt a task and succeed, or not attempt the task at all.
1. https://lore.kernel.org/git/211123.86ilwjujmd.gmgdl@evledraar.gmail.com/