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