• Jakob (14/14) Sep 18 2007 I have the following files:
• BCS (2/21) Sep 18 2007 vote += bigNum;
• Gregor Richards (7/32) Sep 18 2007 vote -= bigNum;
• BCS (4/37) Sep 18 2007 What I want is not the compiler trying to find files. What I want is the...
• Nathan Reed (6/9) Sep 18 2007 So you use the -I flag like Kirk mentioned, to tell it where the root is...
• Jakob (4/16) Sep 19 2007 Well, i'm writing a tool which creates makefiles.
• Jarrett Billingsley (9/13) Sep 19 2007 How on earth is it supposed to do that? Scan every directory in the sys...
• BCS (6/27) Sep 19 2007 What I'm thinking of is; start with the given file, if you can't find th...
• Jarrett Billingsley (8/14) Sep 19 2007 So, you want the compiler to check the current directory and one directo...
• kris (3/19) Sep 19 2007 Exactly :p
• Don Clugston (7/22) Sep 20 2007 Neither bud nor rebuild help with this situation.
• Bill Baxter (18/34) Sep 20 2007 If I understand correctly, he wants to check the current directory and
• Kirk McDonald (27/50) Sep 18 2007 I think it requires too much magic.
• Don Clugston (19/42) Sep 19 2007 There's a more conservative case which is really annoying:
• Derek Parnell (9/30) Sep 20 2007 Are you saying that the compiler should always treat the parent of the
• Jakob (8/15) Sep 20 2007 I mean, the compiler should make the search-root fitting with the module...
• Jakob (3/3) Oct 15 2007 Sry for pushing this thread, but will that be fixed any more?
• Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= (4/9) Oct 15 2007 While the newsgroup is a good place for discussion, it's not really an i...

Jakob <a b.com> writes:

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?

BCS <ao pathlink.com> writes:

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;

Gregor Richards <Richards codu.org> writes:

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

BCS <ao pathlink.com> writes:

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.

Nathan Reed <nathaniel.reed gmail.com> writes:

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

Jakob <a b.com> writes:

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.

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"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." 

BCS <ao pathlink.com> writes:

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

"Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:

"BCS" <ao pathlink.com> wrote in message 
news:ce0a3343236848c9c8a90d5226c2 news.digitalmars.com...
 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

So, you want the compiler to check the current directory and one directory 
up.  Why not arbitrarily high up in the directory hierarchy?  It seems like 
you want the compiler to solve this one problem, which is not so much a 
problem as it is a misunderstanding of the correct behavior.

Just compile from the correct directory, use -I, or use a build tool.  It's 
not like there aren't simple solutions already. 

kris <foo bar.com> writes:

Jarrett Billingsley wrote:
 "BCS" <ao pathlink.com> wrote in message 
 news:ce0a3343236848c9c8a90d5226c2 news.digitalmars.com...
 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

 
 So, you want the compiler to check the current directory and one directory 
 up.  Why not arbitrarily high up in the directory hierarchy?  It seems like 
 you want the compiler to solve this one problem, which is not so much a 
 problem as it is a misunderstanding of the correct behavior.
 
 Just compile from the correct directory, use -I, or use a build tool.  It's 
 not like there aren't simple solutions already. 

Exactly :p

use two or more -I options, if you have a weird kinda' install

Don Clugston <dac nospam.com.au> writes:

Jarrett Billingsley wrote:
 "BCS" <ao pathlink.com> wrote in message 
 news:ce0a3343236848c9c8a90d5226c2 news.digitalmars.com...
 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

 
 So, you want the compiler to check the current directory and one directory 
 up.  Why not arbitrarily high up in the directory hierarchy?  It seems like 
 you want the compiler to solve this one problem, which is not so much a 
 problem as it is a misunderstanding of the correct behavior.
 
 Just compile from the correct directory, use -I, or use a build tool.

Neither bud nor rebuild help with this situation.
-I is a hack.

Really, the problem is that the compiler is not consistent in its association
of 
modules with files.

Module names correspond to directories and files in import statements, but they 
do not correspond to anything when used in module statements. That's the issue.

Bill Baxter <dnewsgroup billbaxter.com> writes:

Jarrett Billingsley wrote:
 "BCS" <ao pathlink.com> wrote in message 
 news:ce0a3343236848c9c8a90d5226c2 news.digitalmars.com...
 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

 
 So, you want the compiler to check the current directory and one directory 
 up.  Why not arbitrarily high up in the directory hierarchy?  

If I understand correctly, he wants to check the current directory and 
exactly N directories up, where there are N dots in the name of the 
current module being compiled.  So given

---
module d1.d2.d3.d4.foo;
import f1.f2.f3.bar;
...
---

the compiler Should look for bar relative to ../../../.. (in addition to 
relative to . and the -I dirs).    And it seems to me ../../../.. should
have higher precedence than '.'.

It seems like
 you want the compiler to solve this one problem, which is not so much a 
 problem as it is a misunderstanding of the correct behavior.
 
 Just compile from the correct directory, use -I, or use a build tool.  It's 
 not like there aren't simple solutions already. 

I agree with you that -I is a pretty easy workaround, but I also agree 
with Jakob, BCS, and Don that if you're compiling d1.d2.d3.d4.bar that 
import f1.f2.f3.bar should be treated relative to bar's root, or at 
least looked for there with relatively high priority.

--bb

Kirk McDonald <kirklin.mcdonald gmail.com> writes:

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

Don Clugston <dac nospam.com.au> writes:

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.

Derek Parnell <derek psych.ward> writes:

On Wed, 19 Sep 2007 00:19:46 +0200, 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?

Are you saying that the compiler should always treat the parent of the
current directory as a search root?

One simple workaround is to add "-I.." to the compiler configuration file. 

I have this in my default bud.cfg file, for example.

-- 
Derek Parnell
Melbourne, Australia
skype: derek.j.parnell

Jakob <a b.com> writes:

Derek Parnell schrieb:
 Are you saying that the compiler should always treat the parent of the
 current directory as a search root?
 
 One simple workaround is to add "-I.." to the compiler configuration file. 
 
 I have this in my default bud.cfg file, for example.
 

I mean, the compiler should make the search-root fitting with the
module-names-root.

E.g.:
You have the file "./dir/foo/bar.d", but in this file, the module-name is
specified as "foo.bar".
In this case the compiler should search in "./dir/"

If the current directory is changed to "./dir/foo/", so that the file is
"bar.d" and the module is "foo.bar", the compiler should search in "../".

The module name must fit to the filename!
Otherwise, imports aren't found.

Jakob <a b.com> writes:

Sry for pushing this thread, but will that be fixed any more?

It would be really nice, because i see definetly a bug in it.
Please also tell me if it won't get fixed, because then i'll create a
workaround in my makefile-tool.

Jari-Matti =?ISO-8859-1?Q?M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:

Jakob wrote:

 Sry for pushing this thread, but will that be fixed any more?
 
 It would be really nice, because i see definetly a bug in it.
 Please also tell me if it won't get fixed, because then i'll create a
 workaround in my makefile-tool.

While the newsgroup is a good place for discussion, it's not really an issue
tracker. There are many good ideas archived here, but people just tend to
forget them. I recommend filing a bug, if this feels important.