version.h rebuild change in stable

Cameron Simpson 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 
>> "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 <cs at cskk.id.au>


More information about the Mutt-dev mailing list