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

From: Pip Cet <[email-masked]>
Date: Mon, 20 Jan 2025 20:59:42 +0000

"Andreas Schwab" <[email-masked]> writes:

> On Jan 20 2025, Pip Cet wrote:
>
>> I believe that needs an additional order-only prerequisite
>> (config.status) to work properly in parallel make: calling config.status
>> twice in parallel seems like a very bad idea.  And, of course, a comment
>> explaining it.
>
> The right way to solve this is to tell config.status to only update the
> current target.

Do you mean "./config.status --recheck", or "MAKE='$(MAKE)'
./config.status"?

I may be being very dense, but the second one is never run so modifying
it won't fix the problem.  The first one is run, but doesn't modify
Makefile.  That is right and proper, and I don't see how modifying it to
update "only the current target" (i.e. config.status itself) would help
things in any way.

Here's what I'm currently planning to insert into the Makefile:

# We attempted to use a Makefile.in, but it doesn't exist.  Most likely,
# we were configured in a different tree which uses a different set of
# Makefile.in files, and then the git branch was changed: in that case,
# wait for config.status to be rebuilt and run it.  Then return without
# generating the target: make will reload the new Makefile and the
# problem will have resolved itself.
#
# If the Makefile.in was accidentally deleted, config.status will fail
# with an error message indicating this to the user, and make will
# terminate.
$(SUBDIR_MAKEFILES_IN) $(CONFIG_STATUS_FILES_IN): | config.status
	MAKE='$(MAKE)' ./config.status

This doesn't work if "make -B" is used, but the current Makefile also
fails in that case.  In all other cases I've found, this does the right
thing.

Pip