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

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Wed, 10 Nov 2021 16:58:59 +0100

On Wed, Nov 10 2021, Johannes Schindelin wrote:

> Hi Ævar,
>
> On Wed, 10 Nov 2021, Ævar Arnfjörð Bjarmason wrote:
>
>> If we're not OK with $(wildcard) as a pattern that would mean changing
>> all of these to hardcoded (in some cases quite big) lists somewhere:
>>
>>     [...]
>
> No, it would only mean changing these instances if we have a concrete
> need. I fail to see a concrete need.
>
> That does not mean that we should make the situation even worse by
> converting currently hard-coded lists to wildcards. There is, once again,
> no concrete need for that, and there is the good reason Junio brought up
> against such a churn: it is too sloppy.

I don't it's sloppy. It's just a different approach. It's also an
approach we use now. Add a new build in and your addition in t/*.sh and
Documentation/*.txt will be picked up & built. We just won't pick up the
*.h or builtin/*.c implicitly.

So whether we need to do this now is one thing, but saying it's a big
change in workflow seems to be rather exaggerated.

>> [...] I think we should remove that LIB_H thing entirely.
>
> I think we should take a break from refactoring code where it is unclear
> what purpose the refactoring serves.

I'm not advocating ripping LIB_H out right now, and have not submitted
any patches to do so.

I'm asking you a follow-up question about your claim that LIB_H is
needed for building from a tarball. I don't think it is, but perhaps I'm
missing something.

It would be useful to get an answer to that for the list records, so
that while it's fresh in your mind we can get an answer one way or the
other.

I agree there's no a strong reason to change it now, but being able to
do so in the future might be useful.

At that point someone will probably dig up this thread. Whether "do we
need LIB_H for what Johannes suggested?" is a dead end or not I'll leave
to you.

>> > And to be honest, even `LIB_H` and `FIND_SOURCE_FILE` would quite
>> > potentially better be hard-coded (with a CI check to ensure that
>> > they're up to date).
>>
>> That would be a bug, just because I don't build on Windows doesn't mean
>> that I wouldn't like "make TAGS coccicheck" to find compat/win32/ at
>> all.
>
> Talking about `coccicheck` in the context of the discussion whether we
> should make sweeping changes in our Makefiles, all while we're supposedly
> in the -rc phase, strikes me as a distant tangent of a distant tangent.

For the past few releases I think I've probably submitted more
last-minute rc fixes than most. In my case it's mostly a matter of
starting some builds and waiting for them to complete:
https://xkcd.com/303/

So yeah, I think we should focus around release time, but saying that
any other ongoing discussion is a needless distraction seems like a
bridge too far.

That being said the reason I'm submitting these sorts of fixes now is
directly related to making rc testing easier.

I test on some obnoxiously slow VMs or otherwise limited computers on
the GCC farm. When something breaks between releases having each step of
a bisect take 30m or 60m makes a big difference.

So having a Makefile that doesn't over-build stuff is important to
release testing.

But getting that across has been frustrating at times. I've pretty much
stopped testing on AIX because my few-lines of patches to the Makefile
to make that drastically easier were categorically rejected. The
response to some other things like over-building <xyz> has been
somewhere between "I don't see why you care, my computer is fast enough"
and "why don't you port ccache to <90s era *nix OS that barely compiles
Hello World without issues".