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


_______________________________________________ Help-make mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/help-make

Reply via email to