[m-dev.] For review: fix an alt install dir annoyance

[Warwick Harvey]

Fergus wrote:
> On 07-Jan-2000, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> > Added some extra dependencies to the generated `.d' files, so that local
> > `.int', `.opt', etc. files shadow the installed versions properly (e.g. for
> > when you're trying to build a new version of an already installed library).
> ...
> > (In theory, perhaps this change shouldn't be needed; however, Make has a
> > habit of ignoring pattern rules whenever it feels like it.)
> 
> It would be better if we understood why those pattern rules
> were being ignored (I'm not a big fan of "voodoo" programming ;-).

OK, here's what it does, all in accordance with the Make documentation:

It looks in the current directory, does not find the `.int' file.  So it 
searches the path, and finds the one in the library directory.  It then 
tries applying a bunch of pattern rules, and cannot figure out how to 
rebuild the `.int' file in the library directory (since there is no 
corresponding `.m' file in the library directory).  Since they were only 
pattern rules, it figures the `.int' file didn't need to be rebuilt and does 
nothing.  If instead we have explicit (non-pattern) dependencies, it decides 
that there _is_ something wrong, and that the `.int' file needs to be 
rebuilt.  It then tries to rebuild the `.int' file, but in the current 
directory this time.  In the current directory, the `.m' file is found, and 
the `.int' file is rebuilt correctly.

Based on the above, pattern rules of the form:

	$(MERCURY_INT_DIR)/%.int : %.date
	        @:

(a la those in extras/clpr/Mmakefile) would also fix the problem --- but 
only for the standard installation location.  I don't know whether or not 
one could devise appropriate hackery to get it to include all extra 
directories specified by the user, and I don't particularly want to try.

> > -# Be very careful about changing the following rules.
> > -# The `@:' is a silent do-nothing command.
> > -# It is used to force GNU Make to recheck the timestamp
> > -# on the target file.  (It is a pity that GNU Make doesn't
> > -# have a way of handling these sorts of rules in a nicer manner.)
> 
> That comment should remain;
> if the places where `@:' is used are different,
> then the comment should be moved, not deleted.

Yup, sorry, fixed:

--- save/compiler/modules.m     Sun Jan  9 23:09:11 2000
+++ compiler/modules.m  Sun Jan  9 23:10:03 2000
@@ -1689,6 +1689,15 @@
                module_name_to_file_name(ModuleName, ".date3", no,
                                                        Date3FileName),
 
+               /*
+               ** Be very careful about changing the following rules.
+               ** The `@:' is a silent do-nothing command.
+               ** It is used to force GNU Make to recheck the timestamp
+               ** on the target file.  (It is a pity that GNU Make doesn't
+               ** have a way of handling these sorts of rules in a nicer
+               ** manner.)
+               */
+
                io__write_strings(DepStream, [
                        "\n",
                        Int0FileName, " : ", Date0FileName, "\n",

> Also, with this change in place, should the following
> code from extras/clpr/Mmakefile be deleted?

It shouldn't hurt either way.  It could also be converted to try using the 
builtin library installation support, but it works the way it is.

I'm currently playing with this stuff for clpz (my integer solver plugged 
into clpr).  Once I've got it working satisfactorily, I'll be porting it to 
clpr, and at that point it shouldn't be too hard to back-patch the Mmakefile 
in the main branch.

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