[m-dev.] Strange things in tools/bootcheck (was Re: Problematic Mmake dependencies)

[Fergus Henderson]

On 07-Jul-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> Fergus wrote:
> > On 06-Jul-1999, Warwick Harvey <wharvey at cs.monash.edu.au> wrote:
> > > 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.
> > 
> > Yes.  Given that the number of primary targets is usually pretty small,
> > I think that the cost of an extra file per primary target is acceptable.
> 
> OK, well I've been working on this (have a `.dv' with the variable 
> definitions, and a `.dep' with the rules), and am having trouble getting it 
> to bootcheck.  The problem is that the bootcheck uses the *installed* 
> version of mmake for a number of tasks, rather than one built in an earlier 
> stage.  This breaks the build since the installed version doesn't know about 
> `.dv' files, and thus loses all the variable definitions.

Sounds like a bug in bootcheck.

> I don't know whether this is deliberate or accidental, but I'd guess 
> accidental,

Me too.

> I've tried looking in the logs, but this stuff goes all the 
> way back to version 1.1 of May '95.  :-)

Yes.  However, the cvs repository does in fact go back slightly further ;-)
The log message on bootcheck revision 1.1, which Zoltan checked in,
says "renamed bcheck as bootcheck".  We still have bcheck in the
repository (its in the mercury directory, not the mercury/tools directory).
Curiously, however, the last revision of bcheck does _not_ contain the
mysterious "unset" commands.  So the log message on the change which
renamed bcheck was rather incomplete.

Looking at the diff between the last revision of bcheck and the first
revision of bootcheck, I think I can see the reason for the unset:
originally, we used to use a relative path `../scripts' for MMAKE_DIR.
So invoking mmake in the top-level directory with this set would not work.

Nowadays we use an absolute path `$root/scripts' rather than a relative
path, so I think it should be safe to remove the unset commands.
So go ahead and make whatever changes you need to make things work.

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