How does the compiler look for the files of imports?

[Don Clugston]

Jakob wrote:
> I have the following files:
> 
> foo/bar.d
>     module foo.bar;
>     import lol.rofl;
> 
> lol/rofl.d
>     module lol.rofl;
> 
> 
> If i change to the directory where "foo" and "lol" are in, and do
>     gdc foo/bar.d lol/rofl.d
> it finds all the files.
> 
> If i change to the directory "foo/" and do
>     gdc bar.d ../lol/rofl
> it doesn't compile:
> bar.d:3: module rofl cannot read file 'lol/rofl.d'
> 
> 
> IMHO, the compiler should notice that the module name is 'foo.bar' (and 
> not only 'bar') and so the directory to search for imports is the parent 
> directory. Or what do you think about that?

There's a more conservative case which is really annoying:

foo/bar.d
     module foo.bar;
     import foo.baz;
foo/baz.d
     module foo.baz;

If compiling from inside foo, it complains that it can't find foo/baz.d, even 
though it knows that module foo.bar is found at ../foo/bar.d

But if you have
import baz;
it will work, even though it is probably a bug. (why are foo.bar and baz at the 
same level??)

In practice -- this means that when developing a library, you cannot run your 
tests from inside the same directory. So you always have to use a nasty -I hack.

IMHO: If the module aaa.bbb.ccc; is in file ccc.d in the current directory, then 
any other files in the aaa.bbb package should also be searched for in the 
current directory. But I don't think it should ever look deeper than the current 
directory; as Kirk points out, it can lead to ambiguity.