www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Aargh! Darn "is in multiply defined" errors

reply "Nick Sabalausky" <z a.a> writes:
I've had a few problems with getting "module X is in multiply defined" 
errors before and it usually turned out to be a cryptic way of saying "you 
need annother 'import' statement somewhere". (BTW, Is that going to be fixed 
sometime?)

I seem to be getting something  little weirder now though.  When I compile 
the sources seperately and then link them everything works fine, but when I 
try to compile and link everything in one call to dmd I'm getting that 
multiply defines error on each of my modules.
Feb 14 2005
next sibling parent reply pragma <pragma_member pathlink.com> writes:
In article <cur6d7$1ueq$1 digitaldaemon.com>, Nick Sabalausky says...

I've had a few problems with getting "module X is in multiply defined" 
errors before and it usually turned out to be a cryptic way of saying "you 
need annother 'import' statement somewhere". (BTW, Is that going to be fixed 
sometime?)

I seem to be getting something  little weirder now though.  When I compile 
the sources seperately and then link them everything works fine, but when I 
try to compile and link everything in one call to dmd I'm getting that 
multiply defines error on each of my modules. 


Just a thought: are you making sure that you're using 'private import'?  

If your module has statements like this:


 // example module 'A'
 import std.stdio;
 import std.string;


Then when you import this in a separate file, you get problems:


 import A;
 import std.stdio; // causes collision


So go and change your imports to 'private' instead, since its likely what you're
intending to do:


 // (revised) example module 'A'
 private import std.stdio;
 private import std.string;



- EricAnderton at yahoo
Feb 14 2005
next sibling parent "Nick Sabalausky" <z a.a> writes:
Yea, when I was getting the errors before, I went all paranoid and just 
turned everything into a private import.

"pragma" <pragma_member pathlink.com> wrote in message 
news:cur81m$20jf$1 digitaldaemon.com...

 In article <cur6d7$1ueq$1 digitaldaemon.com>, Nick Sabalausky says...

I've had a few problems with getting "module X is in multiply defined"
errors before and it usually turned out to be a cryptic way of saying "you
need annother 'import' statement somewhere". (BTW, Is that going to be 
fixed
sometime?)

I seem to be getting something  little weirder now though.  When I compile
the sources seperately and then link them everything works fine, but when 
I
try to compile and link everything in one call to dmd I'm getting that
multiply defines error on each of my modules.


 Just a thought: are you making sure that you're using 'private import'?

 If your module has statements like this:


 // example module 'A'
 import std.stdio;
 import std.string;


 Then when you import this in a separate file, you get problems:


 import A;
 import std.stdio; // causes collision


 So go and change your imports to 'private' instead, since its likely what 
 you're
 intending to do:


 // (revised) example module 'A'
 private import std.stdio;
 private import std.string;



 - EricAnderton at yahoo
Feb 14 2005
prev sibling parent reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
 If your module has statements like this:


 // example module 'A'
 import std.stdio;
 import std.string;


 Then when you import this in a separate file, you get problems:


 import A;
 import std.stdio; // causes collision




I couldn't reproduce this behavior. Can you post an example of where an 
import in A will cause a collision?
Feb 14 2005
parent reply pragma <pragma_member pathlink.com> writes:
In article <curdb0$25h4$1 digitaldaemon.com>, Ben Hinkle says...

 If your module has statements like this:


 // example module 'A'
 import std.stdio;
 import std.string;


 Then when you import this in a separate file, you get problems:


 import A;
 import std.stdio; // causes collision




I couldn't reproduce this behavior. Can you post an example of where an 
import in A will cause a collision? 


My apologies.

That's what I get for shooting from the hip, w/o checking with an actual
compiler first.  I cannot, for the life of me, re-create such a problem myself.

Although I *do* recall a day when such errors were easy to create.

- EricAnderton at yahoo
Feb 15 2005
parent Sean Kelly <sean f4.ca> writes:
In article <cutpn4$1fou$1 digitaldaemon.com>, pragma says...

In article <curdb0$25h4$1 digitaldaemon.com>, Ben Hinkle says...

 If your module has statements like this:


 // example module 'A'
 import std.stdio;
 import std.string;


 Then when you import this in a separate file, you get problems:


 import A;
 import std.stdio; // causes collision




I couldn't reproduce this behavior. Can you post an example of where an 
import in A will cause a collision? 


My apologies.

That's what I get for shooting from the hip, w/o checking with an actual
compiler first.  I cannot, for the life of me, re-create such a problem myself.

Although I *do* recall a day when such errors were easy to create.


IIRC this was fixed in the late 90's somewhere.  So I will confirm that it was a
problem at one time, but it shouldn't be any more.


Sean
Feb 15 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z a.a> wrote:

 I've had a few problems with getting "module X is in multiply defined"
 errors before and it usually turned out to be a cryptic way of saying  
 "you
 need annother 'import' statement somewhere". (BTW, Is that going to be  
 fixed
 sometime?)

 I seem to be getting something  little weirder now though.  When I  
 compile
 the sources seperately and then link them everything works fine, but  
 when I
 try to compile and link everything in one call to dmd I'm getting that
 multiply defines error on each of my modules.


I've seen/had this error when a module was missnamed i.e.

[foo.d]
module not_foo;

changing it to

[foo.d]
module foo;

fixes it, you might want to have a quick check that you don't have  
something like that. It may even be caused if the file is in the wrong  
directory i.e.

[c:\d\projects\foo\bar\baz.d]
module foo.not_bar.baz;

Regan
Feb 14 2005
parent reply "Nick Sabalausky" <z a.a> writes:
"Regan Heath" <regan netwin.co.nz> wrote in message 
news:opsl7kmthn23k2f5 ally...

 On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z a.a> wrote:

 I've had a few problems with getting "module X is in multiply defined"
 errors before and it usually turned out to be a cryptic way of saying 
 "you
 need annother 'import' statement somewhere". (BTW, Is that going to be 
 fixed
 sometime?)

 I seem to be getting something  little weirder now though.  When I 
 compile
 the sources seperately and then link them everything works fine, but 
 when I
 try to compile and link everything in one call to dmd I'm getting that
 multiply defines error on each of my modules.


 I've seen/had this error when a module was missnamed i.e.

 [foo.d]
 module not_foo;

 changing it to

 [foo.d]
 module foo;

 fixes it, you might want to have a quick check that you don't have 
 something like that. It may even be caused if the file is in the wrong 
 directory i.e.

 [c:\d\projects\foo\bar\baz.d]
 module foo.not_bar.baz;

 Regan


I'm not using the module statement anywhere :(. Also, if it were a wrong 
directory issue, wouldn't I be getting the problem even when I compile the 
sources seperately?
Feb 14 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 14 Feb 2005 18:30:35 -0500, Nick Sabalausky wrote:


 "Regan Heath" <regan netwin.co.nz> wrote in message 
 news:opsl7kmthn23k2f5 ally...

 On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z a.a> wrote:

 I've had a few problems with getting "module X is in multiply defined"
 errors before and it usually turned out to be a cryptic way of saying 
 "you
 need annother 'import' statement somewhere". (BTW, Is that going to be 
 fixed
 sometime?)

 I seem to be getting something  little weirder now though.  When I 
 compile
 the sources seperately and then link them everything works fine, but 
 when I
 try to compile and link everything in one call to dmd I'm getting that
 multiply defines error on each of my modules.


 I've seen/had this error when a module was missnamed i.e.

 [foo.d]
 module not_foo;

 changing it to

 [foo.d]
 module foo;

 fixes it, you might want to have a quick check that you don't have 
 something like that. It may even be caused if the file is in the wrong 
 directory i.e.

 [c:\d\projects\foo\bar\baz.d]
 module foo.not_bar.baz;

 Regan


 
 I'm not using the module statement anywhere :(. Also, if it were a wrong 
 directory issue, wouldn't I be getting the problem even when I compile the 
 sources seperately?


I usually get this message when I do not use the module statement. In that
case, DMD invents the module name for you, which is typically just the
source file's name minus the path to the source file. And that's usually
the problem - I need to path (read "package") name as well as the module
name.
Anyhow, I've learned to always explicitly place a module name in the file
now, and to make sure it contains the complete package name too.

Of course, this is PITA when you decide to move files around to different
directories, but one doesn't do that too often (now, anyway).

-- 
Derek
Melbourne, Australia
15/02/2005 11:27:45 AM
Feb 14 2005
next sibling parent reply Mike Parker <aldacron71 yahoo.com> writes:
Derek Parnell wrote:

 On Mon, 14 Feb 2005 18:30:35 -0500, Nick Sabalausky wrote:



 Of course, this is PITA when you decide to move files around to different
 directories, but one doesn't do that too often (now, anyway).


And it will become so much less of a PITA when we get a D IDE with a 
refactoring tool on par with what's out there for Java!
Feb 14 2005
parent Chris Sauls <ibisbasenji gmail.com> writes:
I'm personally dreaming of Borland releasing a DBuilder...

-- Chris S

Mike Parker wrote:

 And it will become so much less of a PITA when we get a D IDE with a 
 refactoring tool on par with what's out there for Java!
Feb 14 2005
prev sibling parent reply "Nick Sabalausky" <z a.a> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1mayz93if5xd.xd6a5a6sct97$.dlg 40tude.net...

 On Mon, 14 Feb 2005 18:30:35 -0500, Nick Sabalausky wrote:


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsl7kmthn23k2f5 ally...

 On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z a.a> wrote:

 I've had a few problems with getting "module X is in multiply defined"
 errors before and it usually turned out to be a cryptic way of saying
 "you
 need annother 'import' statement somewhere". (BTW, Is that going to be
 fixed
 sometime?)

 I seem to be getting something  little weirder now though.  When I
 compile
 the sources seperately and then link them everything works fine, but
 when I
 try to compile and link everything in one call to dmd I'm getting that
 multiply defines error on each of my modules.


 I've seen/had this error when a module was missnamed i.e.

 [foo.d]
 module not_foo;

 changing it to

 [foo.d]
 module foo;

 fixes it, you might want to have a quick check that you don't have
 something like that. It may even be caused if the file is in the wrong
 directory i.e.

 [c:\d\projects\foo\bar\baz.d]
 module foo.not_bar.baz;

 Regan


 I'm not using the module statement anywhere :(. Also, if it were a wrong
 directory issue, wouldn't I be getting the problem even when I compile 
 the
 sources seperately?


 I usually get this message when I do not use the module statement. In that
 case, DMD invents the module name for you, which is typically just the
 source file's name minus the path to the source file. And that's usually
 the problem - I need to path (read "package") name as well as the module
 name.
 Anyhow, I've learned to always explicitly place a module name in the file
 now, and to make sure it contains the complete package name too.

 Of course, this is PITA when you decide to move files around to different
 directories, but one doesn't do that too often (now, anyway).

 -- 
 Derek
 Melbourne, Australia
 15/02/2005 11:27:45 AM


Yay! That worked! :) But, I'm not sure I understand why it was having a 
problem when I didn't explicity state the module.

From working with the DMD compiler, this is how I understand things: Lets 
say I have a directory "C:\src\package\foo\" that contains the files 
"main.d" and "mymodule.d". Neither contain a module statement, and "main.d" 
needs to import the mymodule stuff. If I'm in the directory 
"C:\src\package\foo\" when I invoke DMD, then the import statement in 
"main.d" should be "import mymodule;".  However, if I'm in the directory 
"C:\src\" when I invoke DMD, then the line in "main.d" should be "import 
package.foo.mymodule;".  Hence, when I'm invoking from "C:\src\", doesn't 
DMD assume the name for the mymodule stuff to be "package.foo.mymodule" and 
not just "mymodule"? (And I realize, of course, that I could just pass the 
compiler "-I{dir}" instead of actually being in the given directory.)

Hmm, I think I might understand this...tell me if this is correct: Again, 
assume the same files and directory structure as before and that we're 
always invoking from "C:\src\" (Or that we're passing in "-IC:\src\"). When 
the compiler is told to compile "package\foo\mymodule.d" it strips out the 
path and names the module "mymodule". When the compiler parses 
"package\foo\main.d", it reads the line "import package.foo.mymodule;" and 
decides that it needs a module named "package.foo.mymodule". It then looks 
inside "package\foo\", finds the file "package\foo\mymodule.d", and then 
finishes compiling "package\foo\main.d". Then, when it's compiling 
"package\foo\mymodule.d" it strips out the path and names the module simply 
"mymodule". So basically, main.d is referencing the module 
"package.foo.mymodule" and mymodule.d is essentially referencing the module 
"mymodule". Thus we have a conflict between "package.foo.mymodule" and 
"mymodule".

Is this correct? If so, then shouldn't the compiler *not* strip the path?
Feb 14 2005
next sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 14 Feb 2005 22:22:14 -0500, Nick Sabalausky wrote:


 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1mayz93if5xd.xd6a5a6sct97$.dlg 40tude.net...

 On Mon, 14 Feb 2005 18:30:35 -0500, Nick Sabalausky wrote:


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsl7kmthn23k2f5 ally...

 On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z a.a> wrote:

 I've had a few problems with getting "module X is in multiply defined"
 errors before and it usually turned out to be a cryptic way of saying
 "you
 need annother 'import' statement somewhere". (BTW, Is that going to be
 fixed
 sometime?)

 I seem to be getting something  little weirder now though.  When I
 compile
 the sources seperately and then link them everything works fine, but
 when I
 try to compile and link everything in one call to dmd I'm getting that
 multiply defines error on each of my modules.


 I've seen/had this error when a module was missnamed i.e.

 [foo.d]
 module not_foo;

 changing it to

 [foo.d]
 module foo;

 fixes it, you might want to have a quick check that you don't have
 something like that. It may even be caused if the file is in the wrong
 directory i.e.

 [c:\d\projects\foo\bar\baz.d]
 module foo.not_bar.baz;

 Regan


 I'm not using the module statement anywhere :(. Also, if it were a wrong
 directory issue, wouldn't I be getting the problem even when I compile 
 the
 sources seperately?


 I usually get this message when I do not use the module statement. In that
 case, DMD invents the module name for you, which is typically just the
 source file's name minus the path to the source file. And that's usually
 the problem - I need to path (read "package") name as well as the module
 name.
 Anyhow, I've learned to always explicitly place a module name in the file
 now, and to make sure it contains the complete package name too.

 Of course, this is PITA when you decide to move files around to different
 directories, but one doesn't do that too often (now, anyway).

 -- 
 Derek
 Melbourne, Australia
 15/02/2005 11:27:45 AM


 
 Yay! That worked! :) But, I'm not sure I understand why it was having a 
 problem when I didn't explicity state the module.
 
 From working with the DMD compiler, this is how I understand things: Lets 
 say I have a directory "C:\src\package\foo\" that contains the files 
 "main.d" and "mymodule.d". Neither contain a module statement, and "main.d" 
 needs to import the mymodule stuff. If I'm in the directory 
 "C:\src\package\foo\" when I invoke DMD, then the import statement in 
 "main.d" should be "import mymodule;".  However, if I'm in the directory 
 "C:\src\" when I invoke DMD, then the line in "main.d" should be "import 
 package.foo.mymodule;".  Hence, when I'm invoking from "C:\src\", doesn't 
 DMD assume the name for the mymodule stuff to be "package.foo.mymodule" and 
 not just "mymodule"? (And I realize, of course, that I could just pass the 
 compiler "-I{dir}" instead of actually being in the given directory.)
 
 Hmm, I think I might understand this...tell me if this is correct: Again, 
 assume the same files and directory structure as before and that we're 
 always invoking from "C:\src\" (Or that we're passing in "-IC:\src\"). When 
 the compiler is told to compile "package\foo\mymodule.d" it strips out the 
 path and names the module "mymodule". When the compiler parses 
 "package\foo\main.d", it reads the line "import package.foo.mymodule;" and 
 decides that it needs a module named "package.foo.mymodule". It then looks 
 inside "package\foo\", finds the file "package\foo\mymodule.d", and then 
 finishes compiling "package\foo\main.d". Then, when it's compiling 
 "package\foo\mymodule.d" it strips out the path and names the module simply 
 "mymodule". So basically, main.d is referencing the module 
 "package.foo.mymodule" and mymodule.d is essentially referencing the module 
 "mymodule". Thus we have a conflict between "package.foo.mymodule" and 
 "mymodule".
 
 Is this correct? If so, then shouldn't the compiler *not* strip the path?


Use the -op switch of the dmd commandline. That might help you too.

-- 
Derek
Melbourne, Australia
15/02/2005 2:29:25 PM
Feb 14 2005
parent reply "Nick Sabalausky" <z a.a> writes:
 I usually get this message when I do not use the module statement. In 
 that
 case, DMD invents the module name for you, which is typically just the
 source file's name minus the path to the source file. And that's usually
 the problem - I need to path (read "package") name as well as the module
 name.
 Anyhow, I've learned to always explicitly place a module name in the 
 file
 now, and to make sure it contains the complete package name too.

 Of course, this is PITA when you decide to move files around to 
 different
 directories, but one doesn't do that too often (now, anyway).

 -- 
 Derek
 Melbourne, Australia
 15/02/2005 11:27:45 AM


 Yay! That worked! :) But, I'm not sure I understand why it was having a
 problem when I didn't explicity state the module.

 From working with the DMD compiler, this is how I understand things: Lets
 say I have a directory "C:\src\package\foo\" that contains the files
 "main.d" and "mymodule.d". Neither contain a module statement, and 
 "main.d"
 needs to import the mymodule stuff. If I'm in the directory
 "C:\src\package\foo\" when I invoke DMD, then the import statement in
 "main.d" should be "import mymodule;".  However, if I'm in the directory
 "C:\src\" when I invoke DMD, then the line in "main.d" should be "import
 package.foo.mymodule;".  Hence, when I'm invoking from "C:\src\", doesn't
 DMD assume the name for the mymodule stuff to be "package.foo.mymodule" 
 and
 not just "mymodule"? (And I realize, of course, that I could just pass 
 the
 compiler "-I{dir}" instead of actually being in the given directory.)

 Hmm, I think I might understand this...tell me if this is correct: Again,
 assume the same files and directory structure as before and that we're
 always invoking from "C:\src\" (Or that we're passing in "-IC:\src\"). 
 When
 the compiler is told to compile "package\foo\mymodule.d" it strips out 
 the
 path and names the module "mymodule". When the compiler parses
 "package\foo\main.d", it reads the line "import package.foo.mymodule;" 
 and
 decides that it needs a module named "package.foo.mymodule". It then 
 looks
 inside "package\foo\", finds the file "package\foo\mymodule.d", and then
 finishes compiling "package\foo\main.d". Then, when it's compiling
 "package\foo\mymodule.d" it strips out the path and names the module 
 simply
 "mymodule". So basically, main.d is referencing the module
 "package.foo.mymodule" and mymodule.d is essentially referencing the 
 module
 "mymodule". Thus we have a conflict between "package.foo.mymodule" and
 "mymodule".

 Is this correct? If so, then shouldn't the compiler *not* strip the path?


 Use the -op switch of the dmd commandline. That might help you too.

 -- 
 Derek
 Melbourne, Australia
 15/02/2005 2:29:25 PM


That doesn't seem to help.  The only difference that seemed to make was it 
put the object files in the current directory instead of the source's 
directory.
Feb 14 2005
parent "Nick Sabalausky" <z a.a> writes:
 Yay! That worked! :) But, I'm not sure I understand why it was having a
 problem when I didn't explicity state the module.

 From working with the DMD compiler, this is how I understand things: 
 Lets
 say I have a directory "C:\src\package\foo\" that contains the files
 "main.d" and "mymodule.d". Neither contain a module statement, and 
 "main.d"
 needs to import the mymodule stuff. If I'm in the directory
 "C:\src\package\foo\" when I invoke DMD, then the import statement in
 "main.d" should be "import mymodule;".  However, if I'm in the directory
 "C:\src\" when I invoke DMD, then the line in "main.d" should be "import
 package.foo.mymodule;".  Hence, when I'm invoking from "C:\src\", 
 doesn't
 DMD assume the name for the mymodule stuff to be "package.foo.mymodule" 
 and
 not just "mymodule"? (And I realize, of course, that I could just pass 
 the
 compiler "-I{dir}" instead of actually being in the given directory.)

 Hmm, I think I might understand this...tell me if this is correct: 
 Again,
 assume the same files and directory structure as before and that we're
 always invoking from "C:\src\" (Or that we're passing in "-IC:\src\"). 
 When
 the compiler is told to compile "package\foo\mymodule.d" it strips out 
 the
 path and names the module "mymodule". When the compiler parses
 "package\foo\main.d", it reads the line "import package.foo.mymodule;" 
 and
 decides that it needs a module named "package.foo.mymodule". It then 
 looks
 inside "package\foo\", finds the file "package\foo\mymodule.d", and then
 finishes compiling "package\foo\main.d". Then, when it's compiling
 "package\foo\mymodule.d" it strips out the path and names the module 
 simply
 "mymodule". So basically, main.d is referencing the module
 "package.foo.mymodule" and mymodule.d is essentially referencing the 
 module
 "mymodule". Thus we have a conflict between "package.foo.mymodule" and
 "mymodule".

 Is this correct? If so, then shouldn't the compiler *not* strip the 
 path?


 Use the -op switch of the dmd commandline. That might help you too.

 -- 
 Derek
 Melbourne, Australia
 15/02/2005 2:29:25 PM


 That doesn't seem to help.  The only difference that seemed to make was it 
 put the object files in the current directory instead of the source's 
 directory.


Looks like -op isn't supposed to affect module names. Accourding to the docs 
(http://www.digitalmars.com/d/dcompiler.html):

"-op
normally the path for .d source files is stripped off when generating an 
object file name. -op will leave it on."

And according to various parts of this page 
(http://www.digitalmars.com/d/module.html) it's definately supposed to be 
chopping off the path, as it currently does.

It would be nice if it could leave the path for the module names as well. 
But I'm getting the feeling that there's something I'm not understanding 
quite right, because I doubt Walter would have intentionally chosen to strip 
the path from the default module names without a good reason.  Maybe the 
module conflicts are just some sort of obscure bug (Or maybe I'm doing 
something totally wrong). I'll try to play around with this some more 
tomorrow.
Feb 14 2005
prev sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 14 Feb 2005 22:22:14 -0500, Nick Sabalausky <z a.a> wrote:

 "Derek Parnell" <derek psych.ward> wrote in message
 news:1mayz93if5xd.xd6a5a6sct97$.dlg 40tude.net...

 On Mon, 14 Feb 2005 18:30:35 -0500, Nick Sabalausky wrote:


 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsl7kmthn23k2f5 ally...

 On Mon, 14 Feb 2005 16:49:38 -0500, Nick Sabalausky <z a.a> wrote:

 I've had a few problems with getting "module X is in multiply  
 defined"
 errors before and it usually turned out to be a cryptic way of saying
 "you
 need annother 'import' statement somewhere". (BTW, Is that going to  
 be
 fixed
 sometime?)

 I seem to be getting something  little weirder now though.  When I
 compile
 the sources seperately and then link them everything works fine, but
 when I
 try to compile and link everything in one call to dmd I'm getting  
 that
 multiply defines error on each of my modules.


 I've seen/had this error when a module was missnamed i.e.

 [foo.d]
 module not_foo;

 changing it to

 [foo.d]
 module foo;

 fixes it, you might want to have a quick check that you don't have
 something like that. It may even be caused if the file is in the wrong
 directory i.e.

 [c:\d\projects\foo\bar\baz.d]
 module foo.not_bar.baz;

 Regan


 I'm not using the module statement anywhere :(. Also, if it were a  
 wrong
 directory issue, wouldn't I be getting the problem even when I compile
 the
 sources seperately?


 I usually get this message when I do not use the module statement. In  
 that
 case, DMD invents the module name for you, which is typically just the
 source file's name minus the path to the source file. And that's usually
 the problem - I need to path (read "package") name as well as the module
 name.
 Anyhow, I've learned to always explicitly place a module name in the  
 file
 now, and to make sure it contains the complete package name too.

 Of course, this is PITA when you decide to move files around to  
 different
 directories, but one doesn't do that too often (now, anyway).

 --
 Derek
 Melbourne, Australia
 15/02/2005 11:27:45 AM


 Yay! That worked! :) But, I'm not sure I understand why it was having a
 problem when I didn't explicity state the module.

 From working with the DMD compiler, this is how I understand things: Lets
 say I have a directory "C:\src\package\foo\" that contains the files
 "main.d" and "mymodule.d". Neither contain a module statement, and  
 "main.d"
 needs to import the mymodule stuff. If I'm in the directory
 "C:\src\package\foo\" when I invoke DMD, then the import statement in
 "main.d" should be "import mymodule;".  However, if I'm in the directory
 "C:\src\" when I invoke DMD, then the line in "main.d" should be "import
 package.foo.mymodule;".  Hence, when I'm invoking from "C:\src\", doesn't
 DMD assume the name for the mymodule stuff to be "package.foo.mymodule"  
 and
 not just "mymodule"? (And I realize, of course, that I could just pass  
 the
 compiler "-I{dir}" instead of actually being in the given directory.)

 Hmm, I think I might understand this...tell me if this is correct: Again,
 assume the same files and directory structure as before and that we're
 always invoking from "C:\src\" (Or that we're passing in "-IC:\src\").  
 When
 the compiler is told to compile "package\foo\mymodule.d" it strips out  
 the
 path and names the module "mymodule". When the compiler parses
 "package\foo\main.d", it reads the line "import package.foo.mymodule;"  
 and
 decides that it needs a module named "package.foo.mymodule". It then  
 looks
 inside "package\foo\", finds the file "package\foo\mymodule.d", and then
 finishes compiling "package\foo\main.d". Then, when it's compiling
 "package\foo\mymodule.d" it strips out the path and names the module  
 simply
 "mymodule". So basically, main.d is referencing the module
 "package.foo.mymodule" and mymodule.d is essentially referencing the  
 module
 "mymodule". Thus we have a conflict between "package.foo.mymodule" and
 "mymodule".

 Is this correct? If so, then shouldn't the compiler *not* strip the path?


I think the best person to answer this is Walter, with a description of  
how the module system works... unless of course it already exists in the  
documentation?

http://www.digitalmars.com/d/module.html

those docs don't seem to explain the behaviour you saw, perhaps you found  
a bug?

Regan
Feb 14 2005
parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
 I think the best person to answer this is Walter, with a description of 
 how the module system works... unless of course it already exists in the 
 documentation?
 those docs don't seem to explain the behaviour you saw, perhaps you found 
 a bug?


I swear I'm invisible.  I posted a rather long post on this issue (as well 
as some other module issues) back on January 24th.  The only response I got 
was two people talking about something offtopic and Walter basically not 
understanding what I posted, to which I pretty much had to re-explain 
everything to him.

Since then I've seen several topics about the very things I posted, and they 
all get way more attention than my thread ever did.  If Walter DOES in fact 
reply to this thread with an explanation of the current module system and a 
vow to fix it, I will scream.
Feb 15 2005
parent "Regan Heath" <regan netwin.co.nz> writes:
On Tue, 15 Feb 2005 21:22:36 -0500, Jarrett Billingsley  
<kb3ctd2 yahoo.com> wrote:

 I think the best person to answer this is Walter, with a description of
 how the module system works... unless of course it already exists in the
 documentation?
 those docs don't seem to explain the behaviour you saw, perhaps you  
 found
 a bug?


 I swear I'm invisible.  I posted a rather long post on this issue (as  
 well
 as some other module issues) back on January 24th.  The only response I  
 got
 was two people talking about something offtopic and Walter basically not
 understanding what I posted, to which I pretty much had to re-explain
 everything to him.

 Since then I've seen several topics about the very things I posted, and  
 they
 all get way more attention than my thread ever did.  If Walter DOES in  
 fact
 reply to this thread with an explanation of the current module system  
 and a
 vow to fix it, I will scream.


I remember your post.

Long posts can be ignored due to the effort involved in reading and  
understanding them.

This post was long, to tell the truth I didn't bother to read it all  
because at face value it sounds like a case of un-documented behaviour  
which isn't obvious to see at all.

The only solution to which is to document or explain it, and the best  
person to do so is Walter.

Regan
Feb 15 2005