🚀 go-pugleaf

[.. this issue (ie, dynamically constructing the dependency graph
    by user-specified functions/calculations) is a particular interest
    of mine, so I'll add some more-detailed-hence-more-boring points ..]

:::: wsoto@uol.com.br (Walter Encinas)
:::: I need to build a makefile with a make rule that uses a function
:::: result as a dependency. 

::: "Paul D.  Smith" <psmith@gnu.org>
::: You can't.  [.. though you can use gnu make's autorestart feature ..]

:: wsoto@uol.com.br (Walter Encinas)
:: For the sake of curiosity, is any intrinsic reason why make we>
:: doesn't have this feature? 

: "Paul D. Smith" <psmith@gnu.org>
: Makes rules for the order in which it evaluates variables and
: functions have been in existence since the program was first created,
: and are very consistent.  Not to mention that the POSIX standard for
: make requires them (in the case of variables--there are no such things
: as functions in the POSIX standard.)
: 
: It would be extremely confusing, not to mention breaking many, many
: existing makefiles, to change the order of expansion so that it's not
: consistent any longer.  Expansion is hard enough to understand as it is. 

But it wouldn't be confusing, nor break any makefiles, to introduce
a syntax for expanding things at "dependency time", in addition to the
already existing alternatives of expanding things at read-time,
and expanding things at execution time (of an action).

In that sense, there's no intrinsic reason.
Indeed, that's pretty much the reason for the "%" notation
for describing dependencies; the special macros aren't bound, but a
special syntax is introduded to get the job done.

But deeper problems are, first, in gnu make as in most make-like tools the
derivation of the dependency tree is completely segregated from the
firing of any rules or the binding of special purpose macros such
as $* or $@, and second, the rules by which the dependency tree is generated
depend on quickly finding rules which produce a given target name.
If you can execute an arbitrary function at dependency-building-time
that conflicts with this, because it becomes very very difficult to build the tree.  You'd have to execute the function speculatively with trial bindings
of $* and/or $@ and/or $<; and even choosing which trial bindings
to try is a very-difficult-to-solve problem.

So the intrinsic reason for limiting the syntax to "%" notation, 
is so that you can decide if a given rule is going to be involved in
generating a particular target, or depends upon a particular target,
by a simple pattern match.  If that lookup and/or match needed to
include arbitrary processing steps, it would become essentially
impossible to get right enough fast enough.

Now, fixing the other problem (that performing actions is strictly
segregated from building the dependency graph) could be used to arrange
for the dependency graph to be arbitrarily dynamic.  But the semantics
for choosing rules would be quite un-make-like in such a system;
consider for example the Odin system. 

So.  GNU make can acheive lots of the same goals by considering included
file names as targets, and thus running construction actions in several
stages.  There are still some things that a fully dynamic scheme could
do that gnu make has problems with.  And making dependencies calculatable
by rule firing (ie, rewriting the dependency tree on the fly) can be
much cleaner and better-scoped.  But on the whole, restart based on
included file reconstruction is a fairly powerful mechanism and can do
most things adequately, while remaining backwards-compatible with
traditional make's rules for chosing targets to consider. 


Wayne Throop   throopw@sheol.org   http://sheol.org/throopw