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

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

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.

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

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.

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

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.

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.