I have a question regarding the management of object files:

The compiler does not decorate the object filenames in any way that I've noticed. Therefore, what's to stop a module called foo.d within package X clashing with module foo.d from package Y?

I've run into this a couple of times already whereby I'd have to rename modules such that the object files don't clobber each other. I see there's a compiler switch to retain the package name, but that simply tries to place the object file into a subdirectory corresponding to the package name (and which refuses to create the output directory: most frustrating when you want to dump everything and start afresh). However, once these modules are placed into a LIB, won't the name conflict reappear?

One naiive solution would be to place each package into a separate LIB. But then you invite the hideous and unspeakable "LIB ORDER DEPENDENCY" into your life and to that of anyone else who might venture out to use your code.

What is the D resolution for avoiding object name clashes? I mean, there has to be one; right?

Kris wrote:
> I have a question regarding the management of object files:
> 
> The compiler does not decorate the object filenames in any way that I've
> noticed. Therefore, what's to stop a module called foo.d within package X
> clashing with module foo.d from package Y?

Isn't the package and  module name included in the decorated function names within the .obj file?


For example, when I forget to include an .obj file or .lib in the command line, I get something like this:

main.obj(main)
 Error 42: Symbol Undefined _D14myfancypackage1a8squareitFiZi


In this case, the missing file is called myfancypackage\a.d:

module myfancypackage.a;

int squareit(int i)
{
    return i * i;
}

                        module
                        v
     _D14myfancypackage1a8squareitFiZi
         ^-- package      ^-- function


It's all there.

> 
> I've run into this a couple of times already whereby I'd have to rename
> modules such that the object files don't clobber each other. I see there's a
> compiler switch to retain the package name, but that simply tries to place
> the object file into a subdirectory corresponding to the package name (and
> which refuses to create the output directory: most frustrating when you want
> to dump everything and start afresh). However, once these modules are placed
> into a LIB, won't the name conflict reappear?
> 
> One naiive solution would be to place each package into a separate LIB. But
> then you invite the hideous and unspeakable "LIB ORDER DEPENDENCY" into your
> life and to that of anyone else who might venture out to use your code.
> 
> What is the D resolution for avoiding object name clashes? I mean, there has
> to be one; right?

Unless I missed the point of your confusion, as long as they have a different package.module, there shouldn't be a clash.

Did I miss something?

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Kris wrote:
> I have a question regarding the management of object files:
> 
> The compiler does not decorate the object filenames in any way that I've
> noticed. Therefore, what's to stop a module called foo.d within package X
> clashing with module foo.d from package Y?
> 
> I've run into this a couple of times already whereby I'd have to rename
> modules such that the object files don't clobber each other. I see there's a
> compiler switch to retain the package name, but that simply tries to place
> the object file into a subdirectory corresponding to the package name (and
> which refuses to create the output directory: most frustrating when you want
> to dump everything and start afresh). However, once these modules are placed
> into a LIB, won't the name conflict reappear?
> 
> One naiive solution would be to place each package into a separate LIB. But
> then you invite the hideous and unspeakable "LIB ORDER DEPENDENCY" into your
> life and to that of anyone else who might venture out to use your code.
> 
> What is the D resolution for avoiding object name clashes? I mean, there has
> to be one; right?
> 
>
What I've taken to doing is adding a separate build rule in the make file for each package. Before compiling, I create the directory based upon the package name. So on windows:

=============================================================
MYPACK.SRC.DIR = $(SRC.DIR)\mypack
MYPACK.SRC = \
	$(MYPACK.SRC.DIR)\file.d \
	...
MYPACK.OBJ.DIR = $(OBJ.DIR)\mypack
MYPACK.OBJ = \
	$(MYPACK.OBJ.DIR)\file.obj \
	...
ALL.OBJ = \
	MYPACK.OBJ

DEFAULT: all

clean_obj:
	rd /Q /S $(OBJ.DIR)

clean_exe:
	rd /Q /S $(BIN.DIR)

clean: clean_obj

cleanall: clean_obj clean_exe

mypack:
	md $(MYPACK.OBJ.DIR)
	dmd $(MYPACK.SRC) -c -od$(MYPACK.OBJ.DIR)

exe:
	dmd $(ALL.OBJ) main.d -od$(MYPACK.OBJ.DIR) -of$(BIN.DIR)\program.exe

all: mypack exe

=============================================================

A bit verbose and simplistic, but it works. So far, it hasn't been much of a maintenance problem since I haven't worked with any overly large projects. With numerous packages I certainly foresee nightmares.

So (object code aside) you're saying that the librarian doesn't persist the name of the originating (enclosing) object file at all, but only the exposed symbols? That would make perfect sense. Duh. Double Duh.

Last time I used lib.exe was, uhhh, in conjunction with 5.25" floppy's ... scary to think about that now. Even scarier to recall that Intel was still frightening the community with their '286 zombie ...

Thx.


"J C Calvarese" <jcc7@cox.net> wrote in message news:cdidra$14rt$1@digitaldaemon.com...
> Kris wrote:
> > I have a question regarding the management of object files:
> >
> > The compiler does not decorate the object filenames in any way that I've noticed. Therefore, what's to stop a module called foo.d within package
X
> > clashing with module foo.d from package Y?
>
> Isn't the package and  module name included in the decorated function names within the .obj file?
>
>
> For example, when I forget to include an .obj file or .lib in the command line, I get something like this:
>
> main.obj(main)
>   Error 42: Symbol Undefined _D14myfancypackage1a8squareitFiZi
>
>
> In this case, the missing file is called myfancypackage\a.d:
>
> module myfancypackage.a;
>
> int squareit(int i)
> {
>      return i * i;
> }
>
>                          module
>                          v
>       _D14myfancypackage1a8squareitFiZi
>           ^-- package      ^-- function
>
>
> It's all there.
>
> >
> > I've run into this a couple of times already whereby I'd have to rename modules such that the object files don't clobber each other. I see
there's a
> > compiler switch to retain the package name, but that simply tries to
place
> > the object file into a subdirectory corresponding to the package name
(and
> > which refuses to create the output directory: most frustrating when you
want
> > to dump everything and start afresh). However, once these modules are
placed
> > into a LIB, won't the name conflict reappear?
> >
> > One naiive solution would be to place each package into a separate LIB.
But
> > then you invite the hideous and unspeakable "LIB ORDER DEPENDENCY" into
your
> > life and to that of anyone else who might venture out to use your code.
> >
> > What is the D resolution for avoiding object name clashes? I mean, there
has
> > to be one; right?
>
> Unless I missed the point of your confusion, as long as they have a different package.module, there shouldn't be a clash.
>
> Did I miss something?
>
> --
> Justin (a/k/a jcc7)
> http://jcc_7.tripod.com/d/