Thread overview
"module is in multiple packages" error
Jan 03, 2007
Jona Joachim
Jan 04, 2007
Johan Granberg
Jan 04, 2007
Jona Joachim
Jan 04, 2007
Jona Joachim
Jan 04, 2007
Kirk McDonald
Jan 05, 2007
Jona Joachim
Jan 04, 2007
Frits van Bommel
January 03, 2007
Hi!
I have to bother you with a beginner problem...
I want to develop a spring model engine where you have pointmasses
attached to spring which oscillate and stuff.
I created a module called "connectors" which contains all sorts of
connectors like springs, dampers, ... and a module called "point" which
contains pointmasses and hooks.
Now a connector should know what pointmasses are attached to it and a
pointmass should know to which connectors it is attached...
That's why point.d does a "private import connector" and connector.d does
a "private import point". This works very well in C with header files and
#ifdefs. However gdc throws following error:

gdc -I/home/jona/prog/d/derelict -O2 -fno-strict-aliasing -c point.d connector.d:5: module constructor.point is in multiple packages constructor.point gmake: *** [point.o] Error 1

Could anybody tell me how I should manage this kind of situation?

Thanks a lot,
Jona
January 04, 2007
Jona Joachim wrote:

> Hi!
> I have to bother you with a beginner problem...
> I want to develop a spring model engine where you have pointmasses
> attached to spring which oscillate and stuff.
> I created a module called "connectors" which contains all sorts of
> connectors like springs, dampers, ... and a module called "point" which
> contains pointmasses and hooks.
> Now a connector should know what pointmasses are attached to it and a
> pointmass should know to which connectors it is attached...
> That's why point.d does a "private import connector" and connector.d does
> a "private import point". This works very well in C with header files and
> #ifdefs. However gdc throws following error:
> 
> gdc -I/home/jona/prog/d/derelict -O2 -fno-strict-aliasing -c point.d connector.d:5: module constructor.point is in multiple packages constructor.point gmake: *** [point.o] Error 1
> 
> Could anybody tell me how I should manage this kind of situation?
> 
> Thanks a lot,
> Jona

Try declaring the modules explicityl.

in point.d you write:
module point;//or directoryname.subdirectoryname.point

and in constructor you write:
module constructor;

if this doesent work how does you directory structur looks like (is point and constructor in the same directory?)
January 04, 2007
Jona Joachim wrote:
> Now a connector should know what pointmasses are attached to it and a
> pointmass should know to which connectors it is attached...
> That's why point.d does a "private import connector" and connector.d does
> a "private import point". This works very well in C with header files and
> #ifdefs. However gdc throws following error:
> 
> gdc -I/home/jona/prog/d/derelict -O2 -fno-strict-aliasing -c point.d
> connector.d:5: module constructor.point is in multiple packages constructor.point
> gmake: *** [point.o] Error 1
> 
> Could anybody tell me how I should manage this kind of situation?

I believe GDC has a special flag to work around this. I don't have it installed on this computer, but IIRC 'man gdc' should tell you what it is.

Or you could use DMD which I believe has no such restriction. Will only work for x86 Windows & Linux though...
January 04, 2007
On Thu, 04 Jan 2007 01:17:33 +0100, Johan Granberg wrote:

> Jona Joachim wrote:
> 
>> Hi!
>> I have to bother you with a beginner problem...
>> I want to develop a spring model engine where you have pointmasses
>> attached to spring which oscillate and stuff.
>> I created a module called "connectors" which contains all sorts of
>> connectors like springs, dampers, ... and a module called "point" which
>> contains pointmasses and hooks.
>> Now a connector should know what pointmasses are attached to it and a
>> pointmass should know to which connectors it is attached...
>> That's why point.d does a "private import connector" and connector.d does
>> a "private import point". This works very well in C with header files and
>> #ifdefs. However gdc throws following error:
>> 
>> gdc -I/home/jona/prog/d/derelict -O2 -fno-strict-aliasing -c point.d connector.d:5: module constructor.point is in multiple packages constructor.point gmake: *** [point.o] Error 1
>> 
>> Could anybody tell me how I should manage this kind of situation?
>> 
>> Thanks a lot,
>> Jona
> 
> Try declaring the modules explicityl.
> 
> in point.d you write:
> module point;//or directoryname.subdirectoryname.point
> 
> and in constructor you write:
> module constructor;
> 
> if this doesent work how does you directory structur looks like (is point and constructor in the same directory?)

"constructor" is the (temporary) name of the project. All files are in the
same directory. I declared all modules explicitly like this:
module constructor.point;
or
module constructor.connector;
and so on.

I just found out that my problem disappears when I omit the
"constructor." part.
I don't understand why it all went fine using the above naming scheme
until two modules tried to import themselves mutually and then in that
case it didn't work anymore.
However I'm happy that it seems to work now!

Thanks for your help!

Jona
January 04, 2007
Jona Joachim wrote:
> On Thu, 04 Jan 2007 01:17:33 +0100, Johan Granberg wrote:
> 
>> Jona Joachim wrote:
>>
>>> Hi!
>>> I have to bother you with a beginner problem...
>>> I want to develop a spring model engine where you have pointmasses
>>> attached to spring which oscillate and stuff.
>>> I created a module called "connectors" which contains all sorts of
>>> connectors like springs, dampers, ... and a module called "point" which
>>> contains pointmasses and hooks.
>>> Now a connector should know what pointmasses are attached to it and a
>>> pointmass should know to which connectors it is attached...
>>> That's why point.d does a "private import connector" and connector.d does
>>> a "private import point". This works very well in C with header files and
>>> #ifdefs. However gdc throws following error:
>>>
>>> gdc -I/home/jona/prog/d/derelict -O2 -fno-strict-aliasing -c point.d
>>> connector.d:5: module constructor.point is in multiple packages
>>> constructor.point gmake: *** [point.o] Error 1
>>>
>>> Could anybody tell me how I should manage this kind of situation?
>>>
>>> Thanks a lot,
>>> Jona
>> Try declaring the modules explicityl.
>>
>> in point.d you write:
>> module point;//or directoryname.subdirectoryname.point
>>
>> and in constructor you write:
>> module constructor;
>>
>> if this doesent work how does you directory structur looks like (is point
>> and constructor in the same directory?)
> 
> "constructor" is the (temporary) name of the project. All files are in the
> same directory. I declared all modules explicitly like this:
> module constructor.point;
> or
> module constructor.connector;
> and so on.
> 
> I just found out that my problem disappears when I omit the
> "constructor." part.
> I don't understand why it all went fine using the above naming scheme
> until two modules tried to import themselves mutually and then in that
> case it didn't work anymore.
> However I'm happy that it seems to work now!
> 
> Thanks for your help!
> 
> Jona

Aha!  There's your problem, then.  :)  You were declaring your modules as "constructor.point" and then attempting to import them as "point".  Therefore the compiler was seeing a package mismatch between package "constructor" and package-blank (or the no-package, or whatever you want to call it).  Imports use the fully qualified name of the module, but this name is technically determined by the initial "module X;" statement of the target module.  Modules within the same package /still/ use the fully qualified name to specify imports.

For example, a selection of the file structure of my own Bovis project:
# bovis/
#   Main
#   Types
#   db/
#     Database
#     Object

In order for bovis.Main to import the Database module, I issue:
import bovis .db .Database ;

In order for bovis.db.Database to import the Object module, I issue:
import bovis .db .Object ;

In order for bovis.db.Object to import the Types module, I issue:
import bovis .Types ;

All the same.  Hopefully you understand what I'm trying to get across.  :)

-- Chris Nicholson-Sauls
January 04, 2007
On Wed, 03 Jan 2007 21:45:17 -0600, Chris Nicholson-Sauls wrote:

> Jona Joachim wrote:
>> On Thu, 04 Jan 2007 01:17:33 +0100, Johan Granberg wrote:
>> 
>>> Jona Joachim wrote:
>>>
>>>> Hi!
>>>> I have to bother you with a beginner problem...
>>>> I want to develop a spring model engine where you have pointmasses
>>>> attached to spring which oscillate and stuff.
>>>> I created a module called "connectors" which contains all sorts of
>>>> connectors like springs, dampers, ... and a module called "point" which
>>>> contains pointmasses and hooks.
>>>> Now a connector should know what pointmasses are attached to it and a
>>>> pointmass should know to which connectors it is attached...
>>>> That's why point.d does a "private import connector" and connector.d does
>>>> a "private import point". This works very well in C with header files and
>>>> #ifdefs. However gdc throws following error:
>>>>
>>>> gdc -I/home/jona/prog/d/derelict -O2 -fno-strict-aliasing -c point.d connector.d:5: module constructor.point is in multiple packages constructor.point gmake: *** [point.o] Error 1
>>>>
>>>> Could anybody tell me how I should manage this kind of situation?
>>>>
>>>> Thanks a lot,
>>>> Jona
>>> Try declaring the modules explicityl.
>>>
>>> in point.d you write:
>>> module point;//or directoryname.subdirectoryname.point
>>>
>>> and in constructor you write:
>>> module constructor;
>>>
>>> if this doesent work how does you directory structur looks like (is point and constructor in the same directory?)
>> 
>> "constructor" is the (temporary) name of the project. All files are in the
>> same directory. I declared all modules explicitly like this:
>> module constructor.point;
>> or
>> module constructor.connector;
>> and so on.
>> 
>> I just found out that my problem disappears when I omit the
>> "constructor." part.
>> I don't understand why it all went fine using the above naming scheme
>> until two modules tried to import themselves mutually and then in that
>> case it didn't work anymore.
>> However I'm happy that it seems to work now!
>> 
>> Thanks for your help!
>> 
>> Jona
> 
> Aha!  There's your problem, then.  :)  You were declaring your modules as "constructor.point" and then attempting to import them as "point".  Therefore the compiler was seeing a package mismatch between package "constructor" and package-blank (or the no-package, or whatever you want to call it).  Imports use the fully qualified name of the module, but this name is technically determined by the initial "module X;" statement of the target module.  Modules within the same package /still/ use the fully qualified name to specify imports.
> 
> For example, a selection of the file structure of my own Bovis project:
> # bovis/
> #   Main
> #   Types
> #   db/
> #     Database
> #     Object
> 
> In order for bovis.Main to import the Database module, I issue: import bovis .db .Database ;
> 
> In order for bovis.db.Database to import the Object module, I issue: import bovis .db .Object ;
> 
> In order for bovis.db.Object to import the Types module, I issue: import bovis .Types ;
> 
> All the same.  Hopefully you understand what I'm trying to get across.  :)

I thought I had understood how it works but now I'm not so sure anymore...

Here is my folder:

constructor/
	Makefile
	connector.d
	figure.d
	global.d
	main.d
	point.d
	vector.d

Here are the first line of all file (module declaration and imports):

--connector.d--
module constructor.connector;

private import
  constructor.vector,
  constructor.point;

--figure.d--
module constructor.figure;

private import
  constructor.global,
  constructor.vector,
  constructor.point,
  constructor.connector;

--global.d--
module constructor.global;

--main.d--
module constructor.main;

private import
  constructor.global,
  constructor.vector,
  constructor.point,
  constructor.connector;

--point.d--
module constructor.point;

private import
  constructor.global,
  constructor.connector,
  constructor.vector;

--vector.d--
module constructor.vector;

private import
  constructor.global,
  std.math;



If I try to build this:

/home/jona/prog/d/constructor> gmake
/bin/rm -f global.o vector.o point.o connector.o figure.o main.o
gdc -I/home/jona/prog/d/derelict -O2 -fno-strict-aliasing -c global.d
gdc -I/home/jona/prog/d/derelict -O2 -fno-strict-aliasing -c vector.d
vector.d:4: module global cannot read file 'constructor/global.d'
gmake: *** [vector.o] Error 1


It seems like it tries to cd to constructor although it is already in the
constructor folder. According to what you said it should know this because
the name of the modules itself contains "constructor.".
If I just leave out all occurrences of "constructor." it compiles fine.

Jona
January 04, 2007
Jona Joachim wrote:
> It seems like it tries to cd to constructor although it is already in the
> constructor folder. According to what you said it should know this because
> the name of the modules itself contains "constructor.".
> If I just leave out all occurrences of "constructor." it compiles fine.
> 

That's right: try compiling from outside the constructor directory, or add the parent directory to your import path. (You should be able to just add "-I.." to your compilation options, but it's generally better to compile from inside the parent directory.)

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org
January 05, 2007
On Thu, 04 Jan 2007 12:54:34 -0800, Kirk McDonald wrote:

> Jona Joachim wrote:
>> It seems like it tries to cd to constructor although it is already in the
>> constructor folder. According to what you said it should know this because
>> the name of the modules itself contains "constructor.".
>> If I just leave out all occurrences of "constructor." it compiles fine.
>> 
> 
> That's right: try compiling from outside the constructor directory, or add the parent directory to your import path. (You should be able to just add "-I.." to your compilation options, but it's generally better to compile from inside the parent directory.)

Okay, that works!
Thanks a lot!