www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - object file names

reply "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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?
Jul 19 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jul 19 2004
parent "Kris" <someidiot earthlink.dot.dot.dot.net> writes:
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/
Jul 21 2004
prev sibling parent Mike Parker <aldacron71 yahoo.com> writes:
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.
Jul 21 2004