[m-dev.] Problematic Mmake dependencies

[Warwick Harvey]

> Have a look at how we deal with this problem for $(MLOBJS) and $(MLPICOBJS).
> See the code near the end of scripts/Mmake.vars:
> 
> # The generated `.dep' files include rules for targets which may depend
> # on $(MLOBJS) or $(MLPICOBJS).  However, the definition of $(MLOBJS)
> # or $(MLPICOBJS) is in the user's Mmakefile, and the `.dep' files get
> # included *before* the Mmakefile.  The `.dep' files cannot contain
> # those dependency directly, because $(MLOBJS) and $(MLPICOBJS) variables
> # have not yet been defined.
> #
> # Instead, the generated `.dep' files just add the appropriate targets to
> # the $(MLOBJS_DEPS) or $(MLPICOBJS_DEPS) variables, and then we record the
> # dependency of those files on $(MLOBJS) or $(MLPICOBJS) here in Mmake.rules,
> # which gets included after the user's Mmakefile.

Cute.

> This approach is also a little complicated, but I think it is slightly
> better than the two alternatives that you suggested.  However, I don't know
> off-hand whether this kind of approach is sufficiently powerful to handle
> your case.

It doesn't seem to solve the whole problem.  I can't see how one can get 
this to take into account per-file variable settings.  One could take an 
ultra-conservative approach and have all the files depend on the union of 
the per-file dependencies, but that seems unsatisfactory.

[... several hours later ...]

In fact, I think I can now say with reasonable confidence that this kind of 
approach cannot work.  To have the dependencies work based on per-file 
variables, one needs something along the lines of:

...%... : $(BLAH)

You need the pattern because this will appear in the static rule section and 
you can't just list the targets individually.  This means that $(BLAH) needs 
to expand to something based on the value of `%'.  The problem is, variables 
in the dependency list are expanded at the time they are read, and at the 
time they are read, `%' is just `%'.  The result after variable expansion is 
a "static" list of file names, possibly containing `%'s, but not containing 
any variables.  You get one fixed pattern rule, not a family of pattern 
rules with different dependencies depending on what the target is (which is 
what we need).

So any scheme which has all the automatically generated variable and rule 
definitions (i.e. what's in the `.dep' file now) before all the 
user-specified variable definitions (from the Mmakefile) cannot 
automatically add per-file dependencies based on user-defined variables.

:-(

(Just for the record, the problem is how to add .init file [and library 
file] dependencies automatically, based on variables set in the user's 
Mmakefile --- with the caveat that it should take into account any per-file 
definitions.)

Of the two "splitting" options discussed last time, I think the (physical) 
splitting of the `.dep' file is the better one.  It's only one extra file 
per primary target (executable, library, whatever), and probably (?) 
requires less of a performance hit every time mmake is invoked.

Or one could just leave it unimplemented but documented, but that seems 
rather unsatisfying.

Warwick

--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------