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