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

Previous Next

Full log

View this message in rfc822 format

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: bug#75655: configure doesn't update Makefile
Date: Thu, 23 Jan 2025 20:54:59 +0000

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

>> Date: Thu, 23 Jan 2025 17:50:23 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: schwab <at> linux-m68k.org, 75655 <at> debbugs.gnu.org
>>
>> "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.
>
> I don't see how this is relevant.  "git clean" should be run in the
> source tree (the build tree is not a Git checkout), and the other
> fixes are for very specific problems.

I think it is relevant: The fixes in INSTALL.REPO will not work in the
out-of-tree case, no matter where you run them.  You suggested
"out-of-tree" builds to me, and it sounded like you thought they'd help
fix or avoid this issue.  They don't.

>> 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.
>
> Fair enough, but you are proposing changes to Emacs's build machinery,
> so this is not just about you and your personal workflows, right?

Absolutely.  I seriously do think that several other people will run
into this issue when scratch/elisp-benchmarks is (rebuilt and) merged.

They'll try to bisect something, test a post-merge revision, try to test
a pre-merge revision, it'll fail to build with a strange error message,
they'll try 'make bootstrap', it'll fail with the same message, bug hunt
stymied.

I'd feel responsible for that, and I want to save them the troubles I
had.  That we have instructions hintin at this case indicates this isn't
the first time it's happened, so it's unlikely to be the last time
unless we fix it for good.

OOT builds are unrelated.  Unless I can chmod a-w my emacs source
directory and build from it, they're not "out of tree", and they're not
for me.

Pip

Previous Next

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