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

From: Eli Zaretskii <[email-masked]>
Date: Thu, 23 Jan 2025 17:07:56 +0200

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