version.h rebuild change in stable
cs at cskk.id.au
Sat Jun 1 22:31:01 UTC 2019
On 01Jun2019 14:16, vincent lefevre <vincent at 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
>> 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
>> 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:
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
Cameron Simpson <cs at cskk.id.au>
More information about the Mutt-dev