www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - DMD looks in the wrong place for imports in the same tree

reply Sam McCall <tunah.d tunah.net> writes:
module tunah.a;
import tunah.b;

DMD will look for ./tunah/b.d, rather than ./b.d

Sam
Jul 05 2004
parent reply "Walter" <newshound digitalmars.com> writes:
"Sam McCall" <tunah.d tunah.net> wrote in message
news:ccbd38$1lla$1 digitaldaemon.com...
 module tunah.a;
 import tunah.b;

 DMD will look for ./tunah/b.d, rather than ./b.d

That's the way it's designed to work, imports always work off the current directory, unless you specify a different one with the -I switch.
Jul 06 2004
parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter wrote:

 "Sam McCall" <tunah.d tunah.net> wrote in message
 news:ccbd38$1lla$1 digitaldaemon.com...
 
 module tunah.a;
 import tunah.b;

 DMD will look for ./tunah/b.d, rather than ./b.d

That's the way it's designed to work, imports always work off the current directory, unless you specify a different one with the -I switch.

Is there some hidden advantage to this? digitalmars.D.bugs/586 Stewart. -- My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment. Please keep replies on the 'group where everyone may benefit.
Jul 07 2004
parent reply Arcane Jill <Arcane_member pathlink.com> writes:
In article <ccgeqh$428$1 digitaldaemon.com>, Stewart Gordon says...

digitalmars.D.bugs/586

Gotcha. So if DMD encounters a line like: # module abc.def.ghi; it should implicitly add -I../.. to the include path, on the assumption that that MUST be the module root or the module declaration couldn't possibly be correct. Like it. Of course, if DMD is working the way it's designed to work, this isn't a bug. What you're talking about here is a feature-request (and a good one, too). Maybe this should be talked about over on the main forum? Arcane Jill
Jul 07 2004
parent Sam McCall <tunah.d tunah.net> writes:
(inverted post for my convenience ;)
Arcane Jill wrote:
 Of course, if DMD is working the way it's designed to work, this isn't
 a bug. What you're talking about here is a feature-request (and a good
 one, too). Maybe this should be talked about over on the main forum?

I posted it there when I was frustrated with various things, and annoyed that it didn't work in the obvious (to me) way.
 In article <ccgeqh$428$1 digitaldaemon.com>, Stewart Gordon says...
 
 
digitalmars.D.bugs/586

Gotcha. So if DMD encounters a line like: # module abc.def.ghi; it should implicitly add -I../.. to the include path, on the assumption that that MUST be the module root or the module declaration couldn't possibly be correct.

tree as long as module names and directory names coincide. For example, consider the file /path/tunah/package/foo.d containing each of the following: module foo; import bar.baz; // look in /path/tunah/package/bar/baz.d, // then in phobos/src/bar/baz.d module tunah.example.foo; import tunah.bar.baz; // look in /path/tunah/bar/baz.d, // then in phobos/src/bar/baz.d module contrib.tunah.example.foo; import contrib.tunah.bar.baz; // look in /path/tunah/bar/baz.d, // then in phobos/src/bar/baz.d Lastly, I think either a) these behaviours should be independent of the current working directory you compile from; or b) the current working directory should be searched in the same manner as phobos, before phobos but after module-specific imports. (BTW when I say "phobos" I mean "all global imports", including those given by -I) What are people's thoughts on this? Walter, does this sound like something that'd be suitable if it was popular and someone wrote a non-intrusive, simple patch? I'd be happy to try at some point, though someone else might be better. Sam
Jul 08 2004