Bram Moolenaar wrote:
Tony Mechelynck wrote:
The place of the include should not matter. The Makefile is first read
completely before dependencies are followed. "distclean" does not
depend on auto/config.mk. Perhaps your make program implies this
dependency when including a file? I would call that a bug (some might
call it a feature...).
I'm using GNU make, version 3.80. From "info make", under "Include", I read
the following (about two-thirds of the way down):
[...]
Once it has finished reading makefiles, `make' will try to remake any
that are out of date or don't exist. *Note How Makefiles Are Remade:
Remaking Makefiles. Only after it has tried to find a way to remake a
makefile and failed, will `make' diagnose the missing makefile as a
fatal error.
[...]
In this case, since there is a rule to make auto/config.mk, with
auto/configure, config.mk.in and config.h.in as prerequisites, and one
or more of the latter are newer than the included file config.mk, the
latter is "an out-of-date makefile" and make tries to remake it -- by
running configure. IOW this is a "documented feature" of GNU make.
But I don't want to update auto/config.mk. I can understand that it's
build when it does not exist, otherwise the only alternative is giving
an error message and die. But when it exists it should be used as-is.
I would rather call this a bug than a feature, I didn't specify the file
should be updated. Isn't there a way to disable this "feature"?
[...]
Apparently the "make" philosophy is that one wants to use the most up-to-date
makefiles possible. I'm not sure I understand fully from the make info text if
and how you can avoid to remake an existing makefile if it's present but
out-of-date.
One method would of course be to drop the make rules for config.mk -- but what
would happen when doing "make" the first time without a target? Another
possibility would be to "touch" the config.mk file to make it newer than the
rest -- but is it possible to do that other than manually?
It says in the info text for make that a makefile target with two colons and
no prerequisites will never be remade to avoid an endless loop (unlike a
non-makefile target with two colons and no prerequisites, which is remade
unconditionally IIUC). But double-colon rules are somewhat esoteric and I'm
not sure whether this property is usable.
Best regards,
Tony.