Re: [PATCH] test-lib.sh: discover "git" in subdirs of "contrib/buildsystems/out"

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Mon, Dec 05 2022, Jeff King wrote:

> On Tue, Dec 06, 2022 at 02:43:17AM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> > I don't mind having it in-tree if I can ignore it (assuming the project
>> > attitude is the "it's a side thing" from above). It's the CI failures
>> > that make it hard to ignore.
>> 
>> ...but on this thread-at-large, I'd much rather see us focus on just
>> reviewing the patches I have here than raising the burden of proof to
>> whether we should get rid of it entirely.
>
> Fair. In case it is not obvious, I have no interest in reviewing cmake
> patches. ;) But I will at least stop making noise in the thread.

I'm fine with the running commentary on the future direction, I think
it's also very useful.

I just wanted to also note the need to keep the eyes on the ball a bit
:)

>> If we make the CI failures "soft" failures or move it out-of-tree
>> entirely it would still be useful to be able to run the cmake recipe on
>> *nix.
>
> Agreed.

Just to add my own digression: I asked in some past thread (which I'm
too lazy to dig up) why it was the cmake file couldn't just dispatch to
"make" for most things.

I.e. it needs to at some level be aware of what it's building for the
IDE integration, but for say making a "grep.o" there's no reason it
couldn't be running:

	make grep.o

Instead of:

        cc <args> -o grep grep.c [...]

which requires duplicating much of the Makefile logic (possibly with
some Makefile shim to not consider any dependencies in that case).

Even if we couldn't do that for *.c code for some reason it could do it
e.g. creating the generated *.h files, which is logic we currentnly
duplicate.

The "win+VS build" job even has a hard dependency on GNU make currently,
in needing to run "make artifacts-tar" to get to the "win+VS test"
stage.

But apparently the reason for *that* is that another goal of the
integration was to avoid having to have GNU make installed at all, which
comes in a different package than the one that would ship VS+cmake (or
something?).

Which might be something to re-visit, i.e. maybe we could eventually say
"yes, you can have VS+cmake, but it's not too much to ask that you
install GNU make as a one-off".

Doing that would then reduce the duplication to the point where the
cmake recipe would be a thin shim around the Makefile.

I don't use this development setup, but if the CI job is managing to
download and run GNU make it can't be that hard for an end-user to
similarly install it (but what do I know?).