🚀 go-pugleaf

%% throopw@sheol.org (Wayne Throop) writes:

  wt> But problem (or at least I expect it's a problem; "if I'm wrong
  wt> please correct" (la-la-la)): if what you $(eval) is a set of
  wt> dependencies, and you eval it as part of an action, it won't
  wt> affect the dependency graph currently being walked.

Right.  Nothing about the fundamental algorithms make uses to determine
"out of dateness" has been touched, so of course the problem with
defining new target/prereqisite relationships inside a command script is
that make works from the bottom up: by the time the command script for a
given target is invoked make has already examined all the prerequisites
of that target (and their prerequisites etc.) and has decided to rebuild
the target.  There's little use in defining _more_ prerequisites for
that target (chain) within the command script, as they cannot impact the
build/no-build decision already made and indeed they won't be checked
themselves.  Hmm, it might be interesting to provide a way of adding to
the list of default goals make will try--that way you could at least
add to the targets that will be built.  Hm...

Anyway, that's why I say it's somewhat bizarre to contemplate defining
new targets from within a command script.

  wt> If there were an $(eval-targets ...) with some suitable semantics
  wt> about skipping subsequent lines in the current action based on
  wt> timestamps, one could graft stuff onto the dependency graph on the
  wt> fly, and do things like ensure that generated .h files are
  wt> generated just in time, by calculating new dependencies based on
  wt> intermediate results.

Whoa.  Now you're talking about a whole new beast :).

-- 
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@gnu.org>          Find some GNU make tips at:
 http://www.gnu.org                      http://make.paulandlesley.org
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist