[m-dev.] Problematic Mmake dependencies

[Warwick Harvey]

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?  (The same technique used for the 
system-wide definitions, which are split between the Mmake.vars and 
Mmake.rules files.)  This would appear to make quite a few headaches 
disappear.

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').

Thoughts anyone?

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
--------------------------------------------------------------------------