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

Previous Next

Full log

View this message in rfc822 format

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

> 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
trees, each one configured differently.  That is supported by the
current Makefiles.

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

Then use separate clones.  That's what I do.

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

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

You should not have uncommitted changes, ever.  Always either commit
them (on a local branch if needed) or stash them.  Keeping uncommitted
changes runs the risk of pushing them inadvertently with unrelated
changes (it happened to me and to others).

Previous Next

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