[m-dev.] Problematic Mmake dependencies

[Fergus Henderson]

On 05-Jul-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> Several weeks ago, Fergus wrote:
> > The only time that it is really _crucial_ to include those dependencies
> > are when the `.init' file or the library files in question reside in
> > the same directory as the program using the library.  [...]
> > 
> > So if this is too difficult to implement, then for now I suggest that you
> > just document it with XXX comments in the appropriate places.
> 
> Well, I've been thinking about this one again, and I think the break has 
> given me a little more perspective.  :-)
> 
> The *only* reason this (and similar) dependencies are difficult to implement 
> is because you cannot refer to variables set by the user in the Mmakefile in 
> the dependencies generated in a .dep file.  This is because such variables 
> are expanded immediately, with whatever value they happen to have at the 
> time.  Since the chunk of the generated Makefile that the user specifies 
> comes later, the user cannot change these values "in time".  Just swapping 
> these two chunks over doesn't fix the problem either, because then you 
> cannot use variables set in the .dep files in dependencies in the user's 
> Mmakefile.
> 
> However, is there a particular reason why it would be bad to split the 
> contents of the .dep files so that the variable definitions end up before 
> the user's Mmakefile and the rules after?

Well, the particular reason is just "agh, not more files!".

> There are two ways such a split could be done: replace each .dep file with 
> two files (agh, not more files! :-), or keep them more or less as-is with 
> the split happening when constructing the Makefile (rather than the current 
> simple `cat').

The first approach is more elegant, IMHO, but has the "agh, not more files!"
problem.  The second approach is a little complicated and like the first it
too has negative implications for performance.

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.

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.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------