All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Jeff King <peff@peff.net>
Cc: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
	git@vger.kernel.org, "Junio C Hamano" <gitster@pobox.com>
Subject: Re: [PATCH] Makefile: replace most hardcoded object lists with $(wildcard)
Date: Thu, 4 Nov 2021 01:31:55 +0100 (CET)	[thread overview]
Message-ID: <nycvar.QRO.7.76.6.2111040124430.56@tvgsbejvaqbjf.bet> (raw)
In-Reply-To: <YYJy4BuX6JI6p+aV@coredump.intra.peff.net>

[-- Attachment #1: Type: text/plain, Size: 2555 bytes --]

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.

> 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.

> > 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. :-)

So yeah, the vs-build/vs-test combo tries to pay attention to this
intended scenario, and avoids using GNU make or any other of those Unix
tools that much less ubiquitous than some might want to believe.

Ciao,
Dscho

  parent reply	other threads:[~2021-11-04  0:32 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-30 22:32 [PATCH] Makefile: replace most hardcoded object lists with $(wildcard) Ævar Arnfjörð Bjarmason
2021-10-30 23:15 ` Paul Smith
2021-11-01 20:06   ` Ævar Arnfjörð Bjarmason
2021-10-31  8:29 ` Jeff King
2021-10-31 13:00   ` Ævar Arnfjörð Bjarmason
2021-11-03 11:30     ` Jeff King
2021-11-03 14:57       ` Ævar Arnfjörð Bjarmason
2021-11-04  0:31       ` Johannes Schindelin [this message]
2021-11-04  9:46         ` Ævar Arnfjörð Bjarmason
2021-11-04 14:29           ` Philip Oakley
2021-11-04 17:07           ` Junio C Hamano
2021-11-01 19:19 ` [PATCH v2 0/3] " Ævar Arnfjörð Bjarmason
2021-11-01 19:19   ` [PATCH v2 1/3] Makefile: rename $(SCRIPT_LIB) to $(SCRIPT_LIB_GEN) Ævar Arnfjörð Bjarmason
2021-11-01 19:19   ` [PATCH v2 2/3] Makefile: add a utility to dump variables Ævar Arnfjörð Bjarmason
2021-11-01 19:19   ` [PATCH v2 3/3] Makefile: replace most hardcoded object lists with $(wildcard) Ævar Arnfjörð Bjarmason
2021-11-06 10:57     ` Phillip Wood
2021-11-06 14:27       ` Ævar Arnfjörð Bjarmason
2021-11-06 16:49         ` Phillip Wood
2021-11-06 21:13           ` Ævar Arnfjörð Bjarmason
2021-11-09 21:38           ` Junio C Hamano
2021-11-10 12:39             ` Johannes Schindelin
2021-11-10 13:21               ` Ævar Arnfjörð Bjarmason
2021-11-10 14:59                 ` Johannes Schindelin
2021-11-10 15:58                   ` Ævar Arnfjörð Bjarmason
2022-01-21 12:01             ` Ævar Arnfjörð Bjarmason
2022-01-21 17:14               ` Phillip Wood
2022-01-21 18:13                 ` Ævar Arnfjörð Bjarmason
2022-01-22  6:36               ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=nycvar.QRO.7.76.6.2111040124430.56@tvgsbejvaqbjf.bet \
    --to=johannes.schindelin@gmx.de \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.