www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Module Name Resolution

reply Jason C. Wells <example example.com> writes:
I am reading through: https://dlang.org/spec/module.html. I'll 
soon be working through a previous example provided by Mike 
Parker.

I am reading through Ketmar's iv.d/nanovg/package.d:

   module iv.nanovg;
   public import iv.nanovg.nanovg;

This looks like three levels of hierarchy, but is it?

Should I interpret that import as:

iv
  --nanovg
     --nanovg

Perhaps it really means:

iv.nanovg
   --nanovg

I'm a little confused because the corresponding directory in 
ketmar's source code is named "iv.d" rather than "iv" which is 
what I would have thought to find based on the import.

I see mention of a subpackage in my previous thread. Is this how 
a subpackage is implemented?

Thanks,
Jason
Oct 25 2016
next sibling parent reply Jason C. Wells <example example.com> writes:
Suddenly it occurs to me that the module namespace and the 
filesystem namespace do not necessarily have a one for one match, 
even though they do by default. When one specifies all the D 
source files on the command line, any differences between the 
module namespace and the filesystem namespace are handled 
automagically by dmd. The "module" declaration is the code by 
which the module namespace is manually defined.

Hence the repeated advice to supply all the filenames on the 
command line.
Oct 25 2016
parent ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 26 October 2016 at 05:27:53 UTC, Jason C. Wells 
wrote:

 Hence the repeated advice to supply all the filenames on the 
 command line.


this is basically 'cause dmd doesn't automatically compile and 
link imported modules. it you won't specify module in dmd command 
line, dmd will only look for type declarations in that module, 
but will not compile any actual code from it. so the link stage 
fill fail, 'cause it will try to link with non-existing code. the 
easiest way to solve that is just pass all modules to dmd. or use 
rdmd -- it automatically process imports and invokes dmd with 
built module list (that is what i am using, for example).
Oct 25 2016
prev sibling parent reply ketmar <ketmar ketmar.no-ip.org> writes:
On Wednesday, 26 October 2016 at 04:51:23 UTC, Jason C. Wells 
wrote:

 I am reading through Ketmar's iv.d/nanovg/package.d:

   module iv.nanovg;
   public import iv.nanovg.nanovg;

 This looks like three levels of hierarchy, but is it?


it maps to "iv/nanovg/nanovg.d" according to dmd map rules. i 
used to have all the code in package.d, but later moved it out to 
nanovg.d.

i.e. last name is always a file, everything before it is a 
directory.


 I'm a little confused because the corresponding directory in 
 ketmar's source code is named "iv.d" rather than "iv" which is 
 what I would have thought to find based on the import.


this is a repository name. it is supposed to be named just "iv", 
and git names main directory by repository name if you are doing 
a simple clone. my bad, i should have made that clear.


 I see mention of a subpackage in my previous thread. Is this 
 how a subpackage is implemented?


actually, packages and subpackages are just a convenient terms 
for something that is not strictly defined in D. this is more a 
convention: if we'll place all the files in directory, say, 
"mypkg/a.d", "mypkg/b.d", and add package.d there as 
"mypkg/package.d", then we'll be able to just write "import 
mypkg;". dmd will automatically look for "mypkg/package.d" in 
this case.

so, when you're writing "import iv.nanovg;", dmd looks for 
"iv/nanovg/package.d", and process it. package.d does more 
imports, so dmd loads 'em too. the only magic here is special 
"package.d" file.
Oct 25 2016
parent Jason C. Wells <example example.com> writes:
On Wednesday, 26 October 2016 at 05:46:30 UTC, ketmar wrote:


 this is a repository name. it is supposed to be named just 
 "iv", and git names main directory by repository name if you 
 are doing a simple clone. my bad, i should have made that clear.


Ok. That helps.
Oct 25 2016