GNU bug report logs - #75655
configure doesn't update Makefile

Previous Next

Full log

Message #80 received at 75655 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: schwab <at> linux-m68k.org, 75655 <at> debbugs.gnu.org
Subject: Re: bug#75655: configure doesn't update Makefile
Date: Thu, 23 Jan 2025 17:50:23 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> Date: Thu, 23 Jan 2025 13:56:15 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: schwab <at> linux-m68k.org, 75655 <at> debbugs.gnu.org
>>
>> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.