digitalmars.D - How does the compiler look for the files of imports?
- 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...
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
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
BCS wrote:Reply to Jakob,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 RichardsI 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
Reply to Gregor,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.Reply to Jakob,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 RichardsI 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
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
Nathan Reed schrieb:BCS wrote: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.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 19 2007
"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 :PHow 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
Reply to Jarrett,"Jakob" <a b.com> wrote in message news:fcr3a2$2g3j$1 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 failWell, 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 :PHow 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
"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 failSo, 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
Jarrett Billingsley wrote:"BCS" <ao pathlink.com> wrote in message news:ce0a3343236848c9c8a90d5226c2 news.digitalmars.com...Exactly :p use two or more -I options, if you have a weird kinda' installWhat 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 failSo, 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
Jarrett Billingsley wrote:"BCS" <ao pathlink.com> wrote in message news:ce0a3343236848c9c8a90d5226c2 news.digitalmars.com...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.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 failSo, 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.
Sep 20 2007
Jarrett Billingsley wrote:"BCS" <ao pathlink.com> wrote in message news:ce0a3343236848c9c8a90d5226c2 news.digitalmars.com...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 likeWhat 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 failSo, you want the compiler to check the current directory and one directory up. Why not arbitrarily high up in the directory hierarchy?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
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
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
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
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
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
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