On Saturday, 2 September 2017 at 20:03:48 UTC, Jean-Louis Leroy
wrote:
So I have:
jll@ORAC:~/dev/d/tests/modules$ tree
.
├── foo
│ └── bar.d
└── foo.d
foo.d contains:
import foo.bar;
bar.d is empty.
This means bar.d's module name will be inferred by the compiler
[1], which will ignore the path you put it under, yielding the
module name "bar", not "foo.bar" (one of the issues of doing
otherwise would be how the compiler should know at which path
depth the inference should start - and any solution to that other
than simply ignoring the path would be full of special cases):
Modules have a one-to-one correspondence with source files.
The module name is, by default, the file name with the path
and extension stripped off, and can be set explicitly with the
module declaration.
Now I try compiling:
jll@ORAC:~/dev/d/tests/modules$ dmd -c foo.d
This looks like a compiler bug to me (accepts invalid), though
I'm not certain.
jll@ORAC:~/dev/d/tests/modules$ dmd -c foo/bar.d
(No issue here, just an empty module being compiled separately)
So far so good. Now I try it the way dub does it:
jll@ORAC:~/dev/d/tests/modules$ dmd -c foo.d foo/bar.d
foo.d(1): Error: module bar from file foo/bar.d must be
imported with 'import bar;'
What's up?
This doesn't work, because of the inferred module name for
foo/bar.d being "bar".
So the compiler wants you to import it by the name it has
inferred for you (The fix being either specifying the module name
in foo/bar.d as `module foo.bar`, or importing it as via `import
bar;` in foo.d).
[1] https://dlang.org/spec/module.html
