[m-rev.] for tryout and/or review: removing globals from the I/O state

Peter Wang novalazy at gmail.com
Wed Oct 14 16:39:01 AEDT 2009


On 2009-10-14, Zoltan Somogyi <zs at csse.unimelb.edu.au> wrote:
> 
> > --- compiler/make.m     14 Aug 2009 20:37:46 -0000      1.60
> > +++ compiler/make.m     12 Oct 2009 06:01:38 -0000
> > @@ -609,8 +608,9 @@
> >  option_table_hash(AllOptionArgs, Hash, !IO) :-
> > -    globals.io_get_globals(Globals, !IO),
> > -    handle_options(AllOptionArgs, OptionsErrors, _, _, _, !IO),
> > +    handle_given_options(AllOptionArgs, _, _, _,
> > +        OptionsErrors, UpdatedGlobals, !IO),
> > +    % XXX We throw away UpdatedGlobals after computing its hash. Why? -zs
> >
> > We have no other use for the updated globals here.
> 
> I figured that, but in that case, why hash the updated globals and not the
> original ones? Clearly, the updated globals are being hashed because they
> will be or have been used, in which case, why do the update twice?

This code is part of the --track-flags implementation.  We hash the
updated globals[*] because they include module-specific options.  The
hash is then compared with the hash in a MODULE.track_flags file, which
is updated if it differs.  The new timestamp will later force the module
to be recompiled if necessary, but that's later.  We aren't compiling
the module immediately so the updated globals have no more use here.

Peter

[*] actually the options.
--------------------------------------------------------------------------
mercury-reviews mailing list
Post messages to:       mercury-reviews at csse.unimelb.edu.au
Administrative Queries: owner-mercury-reviews at csse.unimelb.edu.au
Subscriptions:          mercury-reviews-request at csse.unimelb.edu.au
--------------------------------------------------------------------------



More information about the reviews mailing list