Re: non-recursive build question

[Noel Yap]

Sandy Currier wrote:

> Whenever a target's rules are run _and_ the target is created/exists, make
> would update the .<target>.sig file with some user defined signature, 
> out-of-the-box either MD5, TLM, or whatever.  Then under user control
> (yet another option), when make did the update check, it would use the
> .<target>.sig file instead of a stat.  If the .sig file did not exist, it would 
> be
> nice to default to the stat.
>
> One thing that would be really cool is if a hash is also taken of the entire,
> expanded target rules and included that in the .<target>.sig file as well.  This
> way, if say a macro was changed that is referenced in the target rules,
> say changing CFLAGS from "-O2" to "-O3", then make could
> determine that the target rules have changed and rebuild the target.
>
> !
>
> With these two enhancements, make would handle some of clearmake's
> functionality.  And it would be soooo cool.

I agree.  The fact that clearmake looks at the build rule is one of its 
features that I really like.  It would be neat to have something like this in 
GNU make.

I'm a little wary of having GNU make create state files on its own, though.  
Maybe if there's an option that allows the user to choose the name and or 
location of the state file, that'd be a little better, but not completely.

Currently I have a clean rule which makefiles tag onto via:

  .PHONY: clean
  clean: FILES += $(MY_FILES)

Pretty much everything in my makefiles are known to the makefile so I can even 
have a rule that deletes everything it doesn't know about (eg old libraries, 
header files, ...) within the directories it does know about:

  .PHONY: cleanup
  cleanup: FILES += $(MY_FILES)

  .PHONY: install
  install: cleanup

State files would put a kink into this.  OTOH, it's not an insurmountable kink 
especially if there's a programmatic way to know the names of the state files.

MTC,
Noel