Greg Minshall (30 March 2022 01:27) replied: > thanks very much for the reply. and, for the hints (on better use of > make functions).
You're welcome. I do recommend reading the make info pages for the details more often than most developers seem to - most of the tools I've seen that claimed to be improvements on make have shown quite clearly that the author didn't know how to use make to do better than their fancy new tool could. >>> something: >>> @touch ${NEWIN} >> It is generally good to let make know what files a rule creates, rather >> than creating files as a side-effect of making a phony target. > i guess this is the key. in my actual application, the "something" rule > is a "git pull", which updates the file system with files about which my > Makefile has no knowledge (other than that, e.g., they end in ".input"). Back when version control was SCCS and RCS, where one had to check out each file explicitly by name, make could handle version control for you (indeed, I had a whole system for RCS-managed files driven by makefiles; I doubt I am the only one). However, with the advent of whole-tree version control, such as CVS, a version control command could cause all manner of change that the rule to drive them could not possibly anticipate or describe to make. With git this is even more the case, if only because git makes easy some things that were hard in CVS. > i guess the "right" solution for me is to do a sub-make at that point, > to make the files in the pattern rules based on the then-current > contents of the file system. I confess I don't see how a sub-make would really help there. I generally do my git changes separately from invoking make - and, even then, incremental builds sometimes require (at least) a purge of generated dependency files, to force their recreation, since interdependencies can all too easily have changed - indeed, whole subdirectories may have been renamed, which is way outside what I would expect make to cope with. Perhaps others on this list have guidance on that. > again, thanks for the reply. and, the tool! As to the tool - I take it you mean make itself - than Paul and GNU.org for that - I cannot claim credit ;^> Eddy.