[m-dev.] for review: introduction of two new directories

[Fergus Henderson]

On 24-Sep-1998, Zoltan Somogyi <zs at cs.mu.OZ.AU> wrote:
> 
> > >  .PHONY: compiler
> > > -compiler: dep_compiler scripts util runtime boehm_gc library
> > > +compiler: dep_compiler util scripts boehm_gc runtime library browser trace
> > 
> > Any particular reason for swapping the order of `util' and `scripts' there?
> 
> To be consistent with the other targets nearby. I wanted to make sure that
> it is apparent that there is a satisfiable partial order of making the
> directories.

OK, but `util' depends on `scripts', not the other way around,
so that would suggest the order should be the other way.

> > Any particular reason for installing the `browser' library before
> > installing the `trace' library?
> 
> No reason, except for consistency with below.

OK, I thought `browser' depended on `trace' but you explain below that the
actual dependency ordering is the other way around, so leave it as it is.

> Does it matter?

I think it is a good idea to install things in bottom-up dependency ordering.

> > > However, since all Mercury code
> > > +# in an executable must be of the same grade, we need to be able to
> > > +# compile the modules in this directory in debug grades as well.
> > 
> > How about compiling this directory with `--trace minimal', then?
> > That would minimize the overhead.
> 
> But not eliminate it. What we actually want is to compile it with *no* events
> and no layouts (except possibly the minimal ones needed for stack tracing),
> and yet still be able to claim that the grade is debug, so that it can be
> linked into a debug grade program.

Yes, but that's difficult, whereas adding a compilation flag is easy.

> > If this is compiled with `--halt-at-warn', as it should be, then the
> > warning will be treated as an error.
> 
> Yes, I agree this should be fixed. However, I don't think
> 
> > One possible solution would be to use nested modules:
> > 
> > 	:- module browser.
> > 	:- interface.
> > 	:- include_module help.
> 
> is a good solution. Really we need a mechanism for saying that a group of
> modules without a main is a package. I recall there was a proposal for this,
> but not what its status is.

Well, my proposal was that we use sub-modules for this, as shown above.
I don't recall any other proposal.

> > That shouldn't be part of this change, should it?
> 
> No, but this is not *a change*, it is only part of one. I only selected
> file diffs; I did not tinker with each file diff.

Well, now that I've specifically pointed out all the parts that don't belong,
I think it shouldn't be too hard for you to isolate the relevant parts that
do belong into a consistent set of changes.

> > > +		# We repeat lib$STD_LIB_NAME.a. The first occurrence is to
> > > +		# pick up objects needed by the program. Since the library
> > > +		# may have been compiled with tracing even though the program
> > > +		# isn't, this may then introduce references to MR_trace, which
> > > +		# will pull in the browser library and possibly other objects
> > > +		# from the standard library.
> > 
> > I thought the main purpose for introducing the two new directories
> > was to avoid problems with cyclic dependencies between libraries.  But from
> > the above, it sounds like there may be cyclic dependencies anyway, i.e.
> > adding the new directories didn't solve the problem.  Is that correct?
> 
> There are two kinds of circularities: build order and reference order.
> The second cannot be avoided as long as both the following are true:
> 
> (1) MR_trace calls Mercury code;
> (2) this Mercury code calls anything in the Mercury standard library.

That statement is not correct.  Both (1) and (2) are *already* the case,
but we currently don't have any reference order cycles.
Reference order cycles can be avoided by using indirect
references rather than direct references.

> As long as it is possible for the Mercury standard library to call MR_trace,
> these two create a circularity of reference, which is why you need the above
> change. I don't think such circularities are much of a problem.

Such circularities would cause linker warnings on most Unix systems.

In the case of building DLLs I think cyclic references cause linker errors.
I think it would be possible to work around that using a multi-pass
build, but that would complicate things quite a lot.

Cyclic references also prevent "QuickStart" on IRIX, I believe.
QuickStart is an optimization that avoids the cost of dynamic linking
at runtime.  Without this optimization, programs take longer to start up.

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