I try to compile any program, say "a.d", with DMD 2.064 beta on Windows. I specify the binary name with the following command line:
-----
dmd -ofa.exe a.d
-----
It says the following:
-----
Error: importing package 'object' requires a 'package.d' file which cannot be found in 'object\package.d'
import path[0] = C:\Tools\dmd\windows\bin\..\..\src\phobos
import path[1] = C:\Tools\dmd\windows\bin\..\..\src\druntime\import
-----
Here, "C:\Tools\dmd" is a valid path to DMD 2.064 beta.
Minimal program, just in case:
-----
void main ()
{
}
-----
The same command line works fine with DMD 2.063.2.
(In reply to comment #2)
> I cannot reproduce this problem.
Even not with my code?
Comment #4 by gassa — 2013-10-14T15:53:06Z
(In reply to comment #2)
> I cannot reproduce this problem.
Sorry, I got the minimal test case wrong.
It turns out that it can be reproduced exactly when you have directory "object"
in the directory where you are compiling "a.d".
The contents of the directory do not seem to matter, it can be empty.
Comment #5 by k.hara.pg — 2013-10-14T23:27:27Z
(In reply to comment #4)
> (In reply to comment #2)
> > I cannot reproduce this problem.
>
> Sorry, I got the minimal test case wrong.
>
> It turns out that it can be reproduced exactly when you have directory "object"
> in the directory where you are compiling "a.d".
>
> The contents of the directory do not seem to matter, it can be empty.
This is invalid issue, as same as bug 11241.
The root package name 'object' is reserved for druntime.
In this case, the 'object/' directory under the current directly hides druntime object.d module. The conflict error is expected behavior.
See also the detailed answer for bug 11241.
http://d.puremagic.com/issues/show_bug.cgi?id=11241#c1
Comment #6 by gassa — 2013-10-15T01:16:52Z
(In reply to comment #5)
> (In reply to comment #4)
> > It turns out that it can be reproduced exactly when you have directory "object"
> > in the directory where you are compiling "a.d".
> >
> > The contents of the directory do not seem to matter, it can be empty.
>
> This is invalid issue, as same as bug 11241.
>
> The root package name 'object' is reserved for druntime.
> In this case, the 'object/' directory under the current directly hides druntime
> object.d module. The conflict error is expected behavior.
>
> See also the detailed answer for bug 11241.
> http://d.puremagic.com/issues/show_bug.cgi?id=11241#c1
Hmm, I see. My use case is compile script in the root, "binary" for .exe, "object" for .obj files, "source" for .d sources, etc. The name seems common enough to consider some further action though:
1. Is there a way to override this behavior by putting path to standard things like object.d before current directory path?
2. What if the standard-things-first order were the default, as we essentially must not have local modules named "object.d" or "core/memory.d" anyway? If we do that on purpose to override the default modules' behavior, we must be aware of what we are doing, and only then we will change the order of paths explicitly.
3. In any case, it is rather cryptic now, the error message and/or documentation can perhaps be improved.