Subject: Re: bug#75655: configure doesn't update Makefile

From: Pip Cet <[email-masked]>
Date: Thu, 23 Jan 2025 17:50:23 +0000

"Eli Zaretskii" <[email-masked]> writes:

>> Date: Thu, 23 Jan 2025 13:56:15 +0000
>> From: Pip Cet <[email-masked]>
>> Cc: [email-masked], [email-masked]
>>
>> The problem is that we might eventually push this to the master branch,
>> and then it becomes a problem of switching between revisions, not
>> branches.  It'd effectively break "git bisect" if a directory is added
>> in the bisection range.
>
> If you mean different builds from the same source tree, then I suggest
> an out-of-tree builds.  You use one source tree and several build

For this problem, the behavior is even worse for out-of-tree builds: the
problem occurs the same way, but one of the suggested fixes from
INSTALL.REPO leaves you without a Makefile, and the other one won't work
but will probably delete valuable data.

> trees, each one configured differently.  That is supported by the
> current Makefiles.

I meant "git bisect".  The idea is that something changed between two
revisions N revisions apart, and you test ceil(log2(N)) revisions until
you find the (hopefully) single commit which broke things.

That's tedious if N is large, and the only reason it's usable at all is
that once we're down to a small-ish range, we can just run "make" and
it'll either work or won't.

If there's a directory-adding commit "near" the one we're trying to
bisect to, we'll jump back and forth across it several times while
bisecting, so we need to check each commit with a full git clean cycle.

>> > My tendency is not to support these cases if the price is significant
>> > complications in our Makefiles
>>
>> Using a wildcard is what we do for m4/*.m4, so my preference, given this
>> constraint, would be to do the $(wildcard) thing.
>
> Like I said: if the changes don't cause complications, I won't object.

Thanks for repeating that.

Sorry I can't address the general git comments/"out of tree" builds in
detail right now.  I find git hard enough to use without committing
changes so I don't actually push them (that one's confusing), and
certainly won't use multiple clones.  "Out of tree" builds are useless
*to me* as long as they create thousands of files in the "source" tree;
in this case, they make the problem worse.

Pip