[m-dev.] for review: automatic header file inclusion guards.

[Fergus Henderson]

On 24-Jan-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> On 24-Jan-2001, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > On 24-Jan-2001, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > > Implement automatic header file multiple inclusion guards.
> > > 
> > > Note that this should not affect the LLDS backend because it doesn't
> > > use header files to implement foreign_decls, so there is no chance of
> > > multiple inclusions.
> > > 
> > > compiler/intermod.m:
> > > 	Output 
> > > 		:- pragma source_file("...").
> > > 		#linenum
> > > 	before :- pragma foreign_decl(...).
> > > 
> > > 	This gives us the original context for foreign_decls, which is
> > > 	unique.
> > 
> > That fails if there is more than one `:- pragma foreign_decl'
> > on the same line.
> 
> This is true.
> 
> > Also that has the problem that Simon Taylor mentioned -- his memory is
> > clearly better than mine! -- about this forcing unnecessary compilation,
> > due to the `.opt' files changing if you add stuff (e.g. comments)
> > which changes the line numbers.
> 
> I feel that this is a cop-out.  
> 
> The re-compilation is necessary, it's just that we have managed to avoid
> it so far by being buggy (incorrect term contexts given to terms that
> migrate via the .opt files).

That's a reasonable point of view.

The question is whether getting the contexts for stuff in `.opt' files
right is worth the efficiency cost.

> Anyway, I don't want to waste time pushing this change past people who
> don't want it.  The other way to do this is to hash the contents of the
> foreign_decl string -- so I will write some code to do this instead.

That doesn't sound like a good idea either.  To avoid hash collisions,
you'd need a cryptographically secure hash function, and that might be
expensive to compute.  Furthermore, it's not the right semantics,
since if the user writes the same `foreign_decl' twice, it should get
included in their program twice, but what you propose would only
include it once.

I think a better approach, at least for the MLDS back-end, would be to
ensure that each foreign_decl gets written to exactly one header file,
namely the one corresponding to the module that defined it.  Other C
files which might need those declarations should #include that header
file, rather than containing a copy of the foreign_decl.  In other words
the MLDS back-end should discard foreign_decls read from `.opt' files,
and just make sure sure that it #includes all the necessary headers.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- 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
--------------------------------------------------------------------------