On 01Jun2019 14:16, vincent lefevre <vinc...@vinc17.org> wrote:
On 2019-06-01 16:36:38 +1000, Cameron Simpson wrote:
I'm an opinionated make user. Can you explain why you want the
"FORCE"
target at all?
The goal is to make sure that version.h is up-to-date after an update
such as "git pull".
Ah, where the file timestamp is not a reliable indicator of change?
Just spitballing here, but might it not be reasonable for "make clean"
to rebuild version.h? It seems like you'd want a make clean after a git
pull anyway.
[...]
Coming around to my opinions here, I think the BSD make is more correct:
version.h got remade in the "FORCE" version of the Makefile, and its
dependents need a rebuild. GNU make's presuming that file content are all
there are - suppose an action changed something else significant not
considered? Eg maybe the build process copies an ACL off version.h or some
other thing beyond the content. Obviously we don't actually do that, but IMO
GNU make is being too clever.
No, a rule with no prerequisites or recipe is undefined behavior in
POSIX, thus can be used as an extension, and this is what GNU make
does (see Section 4.7 Rules without Recipes or Prerequisites).
What if the FORCE target were:
FORCE:
true
so that it had a do-nothing recipe? That feels portable.
The downside is of course that makes version.h unconditionally updated
and that probably forces a rebuild of lots of stuff. Which is why I
don't really think it should be part of the basic make graph. It should
be off in "make clean" or some other preparatory step.
My "GNU being too clever" thing is about GNU checking file contents
before and after the recipe, BTW.
Anyway, it sounds like you have a workaround; I agree with not feeling
obliged to support having one make during configure and another during
build.
Cheers,
Cameron Simpson <c...@cskk.id.au>
