How does the compiler look for the files of imports?

Bill Baxter dnewsgroup at billbaxter.com
Thu Sep 20 06:31:43 PDT 2007


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



More information about the Digitalmars-d mailing list