View mode: basic / threaded / horizontal-split · Log in · Help
February 15, 2005
Re: Aargh! Darn "is in multiply defined" errors
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
February 15, 2005
Re: Aargh! Darn "is in multiply defined" errors
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
February 15, 2005
Re: Aargh! Darn "is in multiply defined" errors
>>>
>>> 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.
February 15, 2005
Re: Aargh! Darn "is in multiply defined" errors
>>>
>>> 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.
February 15, 2005
Re: Aargh! Darn
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
February 15, 2005
Re: Aargh! Darn
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
February 16, 2005
Re: Aargh! Darn "is in multiply defined" errors
> 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.
February 16, 2005
Re: Aargh! Darn "is in multiply defined" errors
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
Next ›   Last »
1 2
Top | Discussion index | About this forum | D home