Well then I think I've found some new bugs in RDMD & xfbuild:

Files:
root/main.d
root/socket.d

main.d:
module main;

import alt.socket;

void main()
{
    foo();
}

socket.d:
module alt.socket;

import std.stdio : writeln;

void foo()
{
    writeln("test");
}

$ RDMD main.d

main.d(2): Error: module socket is in file 'alt\socket.d' which cannot be read
import path[0] = .
import path[1] = C:\DMD\dmd2\windows\bin\..\..\src\phobos
import path[2] = C:\DMD\dmd2\windows\bin\..\..\src\druntime\import


$ xfbuild +o=main.exe main.d socket.d

main.d(4): Error: module socket is in file 'alt\socket.d' which cannot be read
import path[0] = C:\DMD\dmd2\windows\bin\..\..\src\phobos
import path[1] = C:\DMD\dmd2\windows\bin\..\..\src\druntime\import
Build failed: 'dmd @xfbuild.a00e00.rsp' returned 1.

DSSS fails as well.

But DMD works:

$ dmd main.d socket.d
$ main.exe
> test

Rory Mcguire Wrote:

> In Java yes. I D you can use the module declaration to "move" a module.
> e.g.
> filename: socket.d;
> module: alt.socket;
> 
> to import you'd do "import alt.socket;" even if the file is in the same directory as the module using the file.

"Andrej Mitrovic" <andrej.mitrovich@gmail.com> wrote in message news:i4rnl4$2396$1@digitalmars.com...
> Well then I think I've found some new bugs in RDMD & xfbuild:
>
> Files:
> root/main.d
> root/socket.d
>
> main.d:
> module main;
>
> import alt.socket;
>
> void main()
> {
>    foo();
> }
>
> socket.d:
> module alt.socket;
>
> import std.stdio : writeln;
>
> void foo()
> {
>    writeln("test");
> }
>
> $ RDMD main.d
>
> main.d(2): Error: module socket is in file 'alt\socket.d' which cannot be
> read
> import path[0] = .
> import path[1] = C:\DMD\dmd2\windows\bin\..\..\src\phobos
> import path[2] = C:\DMD\dmd2\windows\bin\..\..\src\druntime\import
>
>
> $ xfbuild +o=main.exe main.d socket.d
>
> main.d(4): Error: module socket is in file 'alt\socket.d' which cannot be
> read
> import path[0] = C:\DMD\dmd2\windows\bin\..\..\src\phobos
> import path[1] = C:\DMD\dmd2\windows\bin\..\..\src\druntime\import
> Build failed: 'dmd @xfbuild.a00e00.rsp' returned 1.
>
> DSSS fails as well.
>
> But DMD works:
>
> $ dmd main.d socket.d
> $ main.exe
>> test
>

Hmm, yea that's not going to work with those tools. The whole point of those tools is that you can give them the file with main(), and then they'll figure out all the files that need to be passed to DMD. The only way they can realistically do that is by assuming package names are directory names and module names are file names.

Since your "socket.d" is in a package named "alt", but *not* in a directory called "alt", those tools have absolutely no way to find "socket.d". If you just run DMD directly, then there's no need to programmatically find "socket.d", since you've already said where to find it.

There's only two ways for those tools to find a file if it's in a directory named *differently* than the package name (or to find a file with a different name from the module name) without venturing into fuzzy guesswork-territory:

1. Search the whole filesystem (obviously ain't gonna happen, and really, this is fuzzy guesswork-territory anyway).

2. Have an option so you can tell it "assume that directory '{someDir}' is a possible location for package '{some.package}' " (Ie, kinda like "-I", but for packages other than just "package root"). This could be done, but frankly I see little, if any, use for that kind of flexibility other than obfuscation, so this is not likely to happen either.

What you *can* do, is put "socket.d" in a directory named "alt", and then put directoy "alt" **anywhere** in the filesystem you want, and then pass in "-I{directoryThatContaininsAlt}". *That* should work (Although that *is* currently broken in RDMD, which gave me some trouble the other day, but I filed a patch for it here: http://d.puremagic.com/issues/show_bug.cgi?id=4672 )

I see.

Well, honestly, I would never use this flexibility to begin with. I'm not seeing much benefits in having modules named in one way while keeping them disorganized and in completely different folders. That just causes confusion, for both the programmer and the build tools.

Personally, I'll try to keep it simple here and name the modules and packages exactly like the directories they're in.

Nick Sabalausky Wrote:

> 

Andrej Mitrovic:

> Well, honestly, I would never use this flexibility to begin with. I'm not seeing much benefits in having modules named in one way while keeping them disorganized and in completely different folders. That just causes confusion, for both the programmer and the build tools.
> 
> Personally, I'll try to keep it simple here and name the modules and packages exactly like the directories they're in.

You may vote this:
http://d.puremagic.com/issues/show_bug.cgi?id=3972
But Walter wants that flexibility. And everyone has to pay a cost for that flexibility.

Bye,
bearophile