Re: [PATCH] Makefile: replace most hardcoded object lists with $(wildcard)

Ævar Arnfjörð Bjarmason [off-list ref] writes:

In this case I do think the change is justified. I've personally got a
few local topics that I keep having to (even with rerere) solve
conflicts for due to this list of files, and Junio deals with the same.

Ditto for some of the changes I've made recently to make things
non-.PHONY. That's resulted in major workflow improvements for me,

To me, I haven't noticed any workflow improvements for me, so I do
not see how my name got into the sentence.

But in any case, the selling point of the original cmake integration was
not something to the effect of:

    "nobody should have to change this in anything but ever so this
    re-implementation is a one-off"

I agree that this wasn't how it was sold, but ...

But rather something like:

    "This re-implementation is a one-off, but any updates to both should
    be trivial."

... I do not think this was how it was sold, either.  As far as I
recall, it was rather: this may double the maintenance burden, but
the reward to help casual Windows builders is large enough that
those who want to add the CMake support are willing to bear their
share of the burden.

As someone who's had a couple of recent run-ins with cmake I can tell
you it's really not trivial at all.

Surely.

So given that the selling point of the original change didn't turn out
as was expected I think it's fair to re-visit whether we'd like to take
this path going forward, or to choose another trade-off.

OK.  The rest of the message I am responding to is your revisiting,
I guess.

quoted

The entire point of the CMake configuration is to allow developers on
Windows to use the tools they are used to, to build Git. And believe it or
not, GNU make is not one of those tools! I know. Very hard to believe. :-)

I believe that, the question is why it isn't a better trade-off to just
ask those users to install that software. Our Windows CI is doing it
on-the-fly, so clearly it's not that hard to do it.

Note that I'm not saying that whatever integration those users get in VS
from the special-cause CMake integration should change. We're only
talking about it invoking "make" under the hood in a way that'll be
invisible to the user.

POSIX "sh" isn't native to Windows either, and that CMake file invokes
shellscripts we ship to e.g. build the generated headers, so this
workflow is clearly something that's OK for an end-user once the one-off
hassle of installing a package is over with.