On 02.05.19 01:18, kdevel wrote:
Now I have:
a/main.d
a/b/package.d
a/b/c/package.d
b/package.d and c/package.d as before.
For reference, a/b/c/package.d is this:
module c; package import std.file;
And a/b/package.d starts with:
module b; import c;
a/main.d is
```
import b;
void dummy ()
{
string s = "test";
mkdir (s);
}
```
In cwd a/ with
$ dmd -unittest -main -i -run main.d
I get
b/package.d(2): Error: module `c` is in file 'c.d' which cannot be read
import path[0] = /.../dmd2/linux/bin64/../../src/phobos
import path[1] = /.../dmd2/linux/bin64/../../src/druntime/import
Why does dmd not get it?
If you want c to be part of the package b, you have to state that in the
module declaration and when importing it.
In c/package.d:
module b.c;
In b/package.d:
import b.c;
Module declarations and imports are always absolute. They're not
relative to the current package. If you add a new root directory on top,
you have to adjust those declarations in all files.
I have to supply -I=b explicitly. Which leads
me to
the actual problem I wanted to post:
$ dmd -unittest -main -I=b -run main.d
main.d(6): Error: undefined identifier mkdir
main only imports b. And b doesn't expose mkdir.
You can either import c (or rather b.c) in main, or make b's import of c
public.
By the way, `package import` seems to work just like `public import`,
not restricting anything. Looks like a compiler bug.
The problem I see here is that b passes the isolated unittest. But when
it is used undefined symbols show up. I stumbled over this problem while
using a project as submodule which uses msgpack-d as its submodule. Only
if I restrict
the import like in
import msgpack : unpack, pack;
my submodule's unittest fails right away. My submodule corresponds to
b/package.d in this thread. I suppose the line
package import std.file, core.stdc.string;
in msgpack-d's file packer.d causes the export of mkdir. Right?
"Export" in the sense of D identifier visibility, yes.
Note that an "undefined identifier" error is different from one about an
"undefined reference". The former is the compiler saying it can't find
the definition of a D identifier. The latter is the linker saying it
can't find a symbol in the object files.
