www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - How does the compiler look for the files of imports?

reply 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?
Sep 18 2007
next sibling parent reply 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;
Sep 18 2007
parent reply 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
Sep 18 2007
parent reply 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?
 


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.
Sep 18 2007
parent reply 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
Sep 18 2007
parent reply 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.
Sep 19 2007
parent reply "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."
Sep 19 2007
parent reply 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
 

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.
 

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
Sep 19 2007
parent reply "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.
Sep 19 2007
next sibling parent 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
Sep 19 2007
prev sibling next sibling parent 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.
Sep 20 2007
prev sibling parent 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
Sep 20 2007
prev sibling next sibling parent 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
Sep 18 2007
prev sibling next sibling parent 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.
Sep 19 2007
prev sibling next sibling parent reply 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
Sep 20 2007
parent 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.
Sep 20 2007
prev sibling parent reply 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.
Oct 15 2007
parent 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.
Oct 15 2007