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

[Warwick Harvey]

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.

I don't know whether this is deliberate or accidental, but I'd guess 
accidental, since I can't see any reason why it needs to be done, and it's 
unlikely to break anything since the `mmake' script itself doesn't change 
much --- last change nearly a year ago.  But there are other (probably) 
related things which aren't done the "obvious" way, and which seem extremely 
unlikely to have been done that way unintentionally, so I figure I'm missing 
something...  I've tried looking in the logs, but this stuff goes all the 
way back to version 1.1 of May '95.  :-)  Anyway, enough rambling, it's time 
to be a little more specific.  To quote from tools/bootcheck:

        if (cd stage2 && mmake $mmake_opts $jfactor runtime)
        then
                echo "building of stage 2 runtime successful"
        else
                echo "building of stage 2 runtime not successful"
                exit 1
        fi

        if (cd stage2 && mmake $mmake_opts depend_library depend_browser \
                depend_compiler depend_profiler)
        then
                echo "building of stage 2 dependencies successful"
        else    
                echo "building of stage 2 dependencies not successful"
                exit 1
        fi      

        MMAKE_VPATH=.
        export MMAKE_VPATH
        MMAKE_DIR=$root/scripts
        export MMAKE_DIR
                
        # the `RM_C=:' ensures that the `.c' files do not get deleted
                
        if (cd stage2/library && mmake $mmake_opts $jfactor RM_C=: mercury)
        then
                echo "building of stage 2 library successful"
        else
                echo "building of stage 2 library not successful"
                exit 1
        fi

	[...]

        if (cd stage2/compiler && mmake $mmake_opts $jfactor RM_C=: 
mercury_compile)
        then
                echo "building of stage 2 compiler successful"
        else
                echo "building of stage 2 compiler not successful"
                exit 1
        fi

        unset MMAKE_VPATH
        unset MMAKE_DIR

        if (cd stage2 && mmake $mmake_opts MMAKEFLAGS=$jfactor all)
        then
                echo "building of stage 2 successful"
        else
                echo "building of stage 2 not successful"
                exit 1
        fi

Why are MMAKE_VPATH and MMAKE_DIR not set for building the runtime and the 
dependencies, set for the library, browser, tracer and compiler, and then 
unset for the final build (which does everything left over --- mainly 
documentation)?  What's wrong with just setting them at the start and 
unsetting them at the end (or leaving them set)?  Something similar happens 
with the stage 3, where these variables are set only after the dependencies 
have been built.

Any light which can be shed on this would be appreciated.

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