import and module names question

[Ary Borenszweig]

Thanks Jarrett.

Jarrett Billingsley escribió:
> "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. 
> 
>