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

Previous Next

Full log

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

From: Pip Cet <pipcet <at> protonmail.com>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: "Pip Cet via \"Bug reports for GNU Emacs,
 the Swiss army knife of text editors\"" <bug-gnu-emacs <at> gnu.org>,
 75655 <at> debbugs.gnu.org
Subject: Re: bug#75655: configure doesn't update Makefile
Date: Wed, 22 Jan 2025 20:44:59 +0000

"Andreas Schwab" <schwab <at> linux-m68k.org> writes:

> On Jan 20 2025, Pip Cet wrote:
>
>> If it is, I'm confused because the target $@ of this rule is, in my
>> case, benchmark/Makefile.in.
>
> If config.status cannot create that file then it is not the right
> command to create it.

That's a tautology, yes :-)

I think it is perfectly permissible to rebuild the Makefile and return
without making the target if there is good reason to believe that the
rule was invoked as a prerequisite for building the Makefile.  I don't
think there is a way to check whether that's true; maybe there should
be.

The only real alternative I see is to use $(wildcard) and depend only on
those Makefile.in files which still exist.  While I've always been told
to avoid wildcard prerequisites, we do so in this Makefile anyway, and
it seems to work.

I switch between revisions a lot, and it's not obvious how to fix this
from the error message: bisecting would be much harder if we insisted on
a full git clean for every iteration.  I suppose the problem isn't that
great because new directories aren't created that often.  Still, I'd
hate to leave it unfixed.

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.

Pip

Previous Next

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