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?

Reply to Jakob,

> 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?
> 

vote += bigNum;

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?

I think it requires too much magic.

/
+-foo/
| +-lol/
| | +-rofl.d - module lol.rofl (1)
| +-bar.d - module foo.bar
+-lol/
  +-rofl.d - module lol.rofl (2)

If the current directory is the root of the above, then:

$ gdc -c foo/bar.d

That will find the lol.rofl marked (2). But if the current direcrory is foo/:

$ gdc -c bar.d

This will (currently) find the lol.rofl marked (1).

To answer the question in the subject line, the compiler looks in the current directory and then any directories provided by the -I option. To get your second example working, you just need to add "-I .." to the command-line:

$ gdc bar.d ../lol/rofl.d -I ..

There are too many subtleties involved for the compiler to be able to guess where modules should be.

-- 
Kirk McDonald
http://kirkmcdonald.blogspot.com
Pyd: Connecting D and Python
http://pyd.dsource.org

BCS wrote:
> Reply to Jakob,
> 
>> 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?
>>
> 
> vote += bigNum;
> 
> 

vote -= bigNum;

The compiler should not trounce all over your file system if you give it a broken module name. It's your responsibility to arrange your source such that the compiler can find it, not the compiler's responsibility to seek it out.

 - Gregor Richards

Reply to Gregor,

> BCS wrote:
> 
>> Reply to Jakob,
>> 
>>> 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?
>>> 
>> vote += bigNum;
>> 
> vote -= bigNum;
> 
> The compiler should not trounce all over your file system if you give
> it a broken module name. It's your responsibility to arrange your
> source such that the compiler can find it, not the compiler's
> responsibility to seek it out.
> 
> - Gregor Richards
> 

What I want is not the compiler trying to find files. What I want is the compiler tying to find the root. The files still must be in the correct places, but I don't want to have to run DMD from correct place.

BCS wrote:
> What I want is not the compiler trying to find files. What I want is the compiler tying to find the root. The files still must be in the correct places, but I don't want to have to run DMD from correct place.

So you use the -I flag like Kirk mentioned, to tell it where the root is.

If you don't like having to remember to type that every time, just use a makefile, or your automated build system of choice.

Thanks,
Nathan Reed

Nathan Reed schrieb:
> BCS wrote:
>> What I want is not the compiler trying to find files. What I want is the compiler tying to find the root. The files still must be in the correct places, but I don't want to have to run DMD from correct place.
> 
> So you use the -I flag like Kirk mentioned, to tell it where the root is.
> 
> If you don't like having to remember to type that every time, just use a makefile, or your automated build system of choice.
> 
> Thanks,
> Nathan Reed

Well, i'm writing a tool which creates makefiles.

And if the compiler would analyze the module name to get the module root, it would be much simpler for me :P
Besides, the compiler would not read wrong files as in Kirk's example.

"Jakob" <a@b.com> wrote in message news:fcr3a2$2g3j$1@digitalmars.com...

> Well, i'm writing a tool which creates makefiles.
>
> And if the compiler would analyze the module name to get the module root, it would be much simpler for me :P

How on earth is it supposed to do that?  Scan every directory in the system looking for a sequence of directory names that match the package name of the module?  What if the module has no package names?  What exactly is "the module root"?

> Besides, the compiler would not read wrong files as in Kirk's example.

That's entirely not the compiler's fault.  You can't say "import foo, but not the foo that looks blindingly obvious, I mean the foo that's in some other arbitrary directory on my system.  Yeah, that one.  You know what I'm talking about."

Reply to Jarrett,

> "Jakob" <a@b.com> wrote in message
> news:fcr3a2$2g3j$1@digitalmars.com...
> 
>> Well, i'm writing a tool which creates makefiles.
>> 
>> And if the compiler would analyze the module name to get the module
>> root, it would be much simpler for me :P
>> 
> How on earth is it supposed to do that?  Scan every directory in the
> system looking for a sequence of directory names that match the
> package name of the module?  What if the module has no package names?
> What exactly is "the module root"?
> 
>> Besides, the compiler would not read wrong files as in Kirk's
>> example.
>> 
> That's entirely not the compiler's fault.  You can't say "import foo,
> but not the foo that looks blindingly obvious, I mean the foo that's
> in some other arbitrary directory on my system.  Yeah, that one.  You
> know what I'm talking about."
> 

What I'm thinking of is; start with the given file, if you can't find the imports and they share a common package prefix, check if the containing directory has your package as a suffix. If it does try removing the sufix and then check for the modules. For consistency, If you can't find /all/ imports using this new root in replacement of the current directly, then fail

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.