import and module names question

[Jarrett Billingsley]

"Ary Borenszweig" <ary at esperanto.org.ar> wrote in message 
news:fmbqi6$o01$1 at digitalmars.com...
> I'm currently testing the semantic analysis of Descent, to match it with 
> DMD's. I'm trying to get zero errors on phobos. There's one thing I don't 
> understand. In module internal.gc.gc there's this line:
>
> public import gcx;
>
> At the root of phobos there is no file named gcx.d, but in internal/gc/ 
> there is one. That file doesn't have a module declaration (no "module 
> ...;"). So I thought "Oh, since it doesn't have a module declaration, the 
> module's name is gcx (the filename minus .d), and that's why the public 
> import works". But... When compiling this piece of code:
>
> ---
> import internal.gc.gc;
> ---
>
> I get:
> ..\dmd\bin\..\src\phobos\internal\gc\gc.d(37): module gcx cannot read file 
> 'gcx.d'
>
> So... is there an error in internal.gc.gc? If so... how does phobos gets 
> compiled? Should I ignore that kind of errors while testing Descent on 
> phobos?

The GC is compiled as a single piece of the library.  If you were to compile 
gc.d from the /internal/gc directory, you would import gcx.d by using 
"import gcx;", which is exactly what's going on here.

The downside is that if you're _not_ compiling from /internal/gc, you can't 
import internal.gc.gcx, since now it's nested in a directory, so the FQN now 
becomes "internal.gc.gcx".

So either skip that dir when testing Descent, or set your path to it when 
testing it so that gcx comes into the "root" namespace.