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

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Nov 4, 2021, 09:46 UTC
Message-ID: <211104.86r1bwi6f7.gmgdl@evledraar.gmail.com>
In-Reply-To: <nycvar.QRO.7.76.6.2111040124430.56@tvgsbejvaqbjf.bet>

On Thu, Nov 04 2021, Johannes Schindelin wrote:

Show 22 quoted lines

> Hi Peff,
>
> On Wed, 3 Nov 2021, Jeff King wrote:
>
>> On Sun, Oct 31, 2021 at 02:00:42PM +0100, Ævar Arnfjörð Bjarmason wrote:
>>
>> > I didn't notice before submitting this but this patch breaks the
>> > vs-build job, because the cmake build in "contrib" is screen-scraping
>> > the Makefile[1].
>> >
>> > What's the status of that code? It's rather tiresome to need to patch
>> > two independent and incompatible build systems every time there's some
>> > structural change in the Makefile.
>>
>> My opinion when we took in the cmake topic was that it would be OK for
>> people working on the main Makefile to break cmake. It's an add-on and
>> the people who care about cmake are the ones who will do the work to
>> track the Makefile.
>
> I do try to have a look at breakages in `seen` when I have the time, but
> lately I didn't. That's why you may have felt more of these CMake
> headaches.

It's not only things that make it into "seen", as most will test their topic in GitHub CI before submission in their own repos.

Show 9 quoted lines

>> But since there's a CI job that will nag you if it fails, that kind of
>> makes it everybody's problem in practice. That doesn't change my opinion
>> on how things _should_ work, but I have done small fixups as necessary
>> to stop the nagging.
>
> One very simple solution is to leave the Makefile alone unless it really,
> really needs to be changed. There are costs to refactoring, and quite
> honestly, it might be a good thing that something like a failing vs-build
> job discourages refactoring for refactoring's sake.

Sure, but that's the case with any critical component we're using. A question of "is it worth leaving it alone" is distinct from "is it painful to touch it because you need to implement a fix twice in two incompatible languages?".

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,

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"

But rather something like:

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

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

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.

Show 17 quoted lines

>> > I hadn't looked in any detail at that recipe before, but it the
>> > vs-build job has a hard dependency on GNU make anyway, since we use it
>> > for "make artifacts-tar".
>> >
>> > So whatever cmake special-sauce is happening there I don't see why
>> > vs-build couldn't call out "make" for most of the work it's doing,
>> > isn't it just some replacement for what the "vcxproj" target in
>> > config.mak.uname used to do?
>>
>> The big question for me is whether that really is a hard dependency.
>> Obviously "make artifacts-tar" is for the CI job, but is the cmake stuff
>> supposed to work for regular users without relying on having GNU make at
>> all? I have no clue.
>
> 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.