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 13:56:15 +0000

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

>> Cc: 75655 <at> debbugs.gnu.org
>> Date: Wed, 22 Jan 2025 20:44:59 +0000
>> From:  Pip Cet via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> I switch between revisions a lot, and it's not obvious how to fix this
>> from the error message:
>
> My advice: don't switch Emacs branches in the same directory.  Emacs

Thanks!

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.

> branches are usually quite divergent, and making our build machinery
> 110% resistant to such switches would add complications that are
> unjustified, especially since some dependencies are inherently hard to
> track given the functionality of Make programs.

Thanks.  Some comments below.

> Switching branches in the same directory only works well if the
> branches are similar enough.  Once you get to the situation where
> directories and/or many files are being added/removed by one of the
> branches (something that happens a lot here), problems begin that are
> hard to fix using Make.

> So my advice is to use separate directories for different branches.
> Git supports this even if you don't want to have separate clones
> (which is always a possibility): you can use "git worktree" commands.

I have to use submodules; git submodule and git worktree don't work in
concert.  (There are many other problems with it; my advice is not to
advise people to use "git worktree", as it's a poorly-implemented
command which should be used with great care).

About the "110%", "works well", etc: this case doesn't work at all.  It
produces an error message which only very vaguely hints at the real
problem.

The result will be that most users will start over with a fresh
checkout, which almost certainly results in the loss of commits and
other data once in a while.  (While "git clean" works, it's hard to use
it properly, too).

I'm mostly concerned that "git bisect" will require a full "git clean"
to test each revision while there are added directories in the branch,
or fail mysteriously, meaning we'd incorrectly mark a good commit as
bad.

About the "hard to fix using Make": autogen.sh and configure also fail
to fix this problem unless they're used precisely in one (apparently
redundant) way.

>> A third option would be to use the recipe I proposed, only instead of
>> running config.status, we'd tell the user to, then fail the rule.
>
> 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.

We can explain it with a comment in both places or neither, because
wildcard prerequisites are usally a very bad idea and we should justify
the exception.

This would allow "make bootstrap" to work again, but wouldn't
automatically detect the problem if a Makefile.in file was accidentally
removed from the tree but not from configure.ac.

> and/or redundant regenerations of files/targets (like loaddefs.el
> etc.) that don't need to be regenerated.

The $(wildcard) change would reduce rebuilds, sometimes skipping one
which is arguably necessary, not increase them.

The other patch I proposed would never cause extra rebuilds either,
AFAICT.

However, I must confess I only just found the documentation at the end
of INSTALL.REPO, plainly advising developers to run "git clean -fdx" in
such cases, unconditionally destroying uncommitted changes and new
files.

This is extremely dangerous advice!  This is particularly true since we
know that it is likely development work just happened in that directory.

If we can't remove the advice (the first case has already been made
unnecessary (commit 4939f58d2c45062d5eac3f4c845b4494cf113f1f); the
$(wildcard) proposal merely does the same thing for the second case), we
should, at least, recommend "git clean --interactive -dX" instead.

-i rather than -f asks the user for confirmation; -X instead of -x will
avoid the unnecessary deletion of files we're almost certain are
valuable. This option and the "-d" option don't have long equivalents.

Confirmed to work in this case.

Pip

Previous Next

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