[Mono-list] Some questions about shared assemlies, strong names...
Fri, 9 May 2003 00:44:30 +1000
On 06-May-2003, Paolo Molaro <firstname.lastname@example.org> wrote:
> On 05/05/03 Fergus Henderson wrote:
> > > Since the gc.dll in mercury should be just an helper dll, I suggest
> > > renaming it to mercury-gc.dll or something like that: I think this is a
> > > good idea regardless of the name clash issues.
> > That's easier said than done. The Mercury build system compiles each
> > Mercury module "foo" (in source file "foo.m") to "foo.dll". The file
> > "gc.dll" comes from the Mercury standard library module named "gc".
> > It's not possible to rename that module, because that would break
> > compatibility with existing Mercury programs that refer to the module
> > by the name "gc" in their source code.
> Well, I guess the mercury code either loads the module using a method
> provided by your mercury implementation or it is linked in automatically
> by the compiler. In boh cases the name of the file on disk shold not
> matter much, right?
In principle the name of the file on disk doesn't matter much, but the
fact that the name of the file on disk matches the module name does
matter -- breaking that invariant would require considerable changes to
the Mercury build system.
We can't just build gc.dll using the Mercury build system and then copy
it to mercury-gcc.dll, because other dlls in the Mercury standard library
will still refer to gc.dll.
> If I remember correctly gc.dll was a module of the main mercury runtime
> assembly and it was loaded through a type/method reference: I can't see
> nothing in that process that requires the module to be named gc.dll, but
> maybe I'm missing something.
You are suggesting changing the name "gc.dll", but you didn't suggest how.
We didn't explicitly write down the name "gc.dll" anywhere, so it's not
immediately apparent how we should change it.
We can't just change the name "gc.dll" in the Makefile,
because there is no Makefile which mentions "gc.dll";
instead there is only an automatically generated Makefile fragment
This Makefile fragment is automatically generated based on the Mercury
module name. We can't change the Mercury module name because that would
break source compatibility.
Actually, that is oversimplifying. In reality there are two
different Mercury build systems, and we need to be able to
build the Mercury standard library using both of them.
In one of them, there is an automatically generated Makefile
fragment; but in the other, the dependency calculations are
handled directly by the Mercury compiler.
Fergus Henderson <email@example.com> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.