Suggestion: Object filenames should be fully-qualified module names

[Kirk McDonald]

I originally heard this idea proposed by Gregor Richards in #d, and I
think it should become DMD's default behavior. If it is not the default 
behavior, then it should at least be available as an option.

Perhaps my biggest grievance with both the DMD and GDC compilers is
their handling of object files. DMD's default behavior is to dump all
object files into the current directory. If the -od option is specified,
the object files will be placed into the specified directory instead. If
-op is specified, the object files are placed alongside the original 
source files.

The default behavior and using -od on its own both fail if any two 
source files in the project have the same name, even if they are in 
different packages. Using -op by itself is unappealing for two reasons:

1) It is not unreasonable to expect a system to place libraries in 
directories to which the user does not have write access. Placing object 
files alongside the source files would therefore fail.

2) It pollutes the source directories with object files. I much prefer 
keeping my object files somewhere to the side, in a designated "build" 
directory. This makes keeping projects in version control much easier, 
as I can simply exclude the one directory to keep object files out of 
version control.

Specifying both -op and -od causes things to get a little more 
interesting. Take the following:

test.d
testpkg
   test.d

// test.d
module test;
import testpkg.test : foo;
void main() {
     foo();
}

// testpkg/test.d
module testpkg.test;
import std.stdio : writefln;
void foo() { writefln("foo"); }

If we compile with this:

$ dmd test.d testpkg/test.d -op -odbuild

The "build" directory has the following structure:

build
   test.obj
   testpkg
     test.obj

This is all and well. However, if we compile like this:

$ dmd test.d /path/to/testpkg/test.d -op -odbuild

Then DMD doesn't know what to do, and it places testpkg/test.obj 
alongside the source file. (More specifically, the full path is "joined" 
to the path specified by -od, which works out to just being the full path.)

This ambiguity can be disposed of if an object file's name is its 
fully-qualified module name. If this were true, then we could just say

$ dmd test.d testpkg/test.d -odbuild

and the result would be the build directory looking like this:

build
   test.obj
   testpkg.test.obj

I find this very clean and simple. Since the compiler fails anyway if 
two modules have the same name, there should not ever be overlaps in 
object file names with this scheme. The -op option could probably be 
safely deprecated.

As someone pointed out in #d, this would fail on NTFS if the module's 
fully-qualified name exceeds 255 characters. Though I cannot recall ever 
using a module whose name even approached that limit, this should be 
solved in most cases by truncating the filename at the start. 
(Hopefully, the last 255 characters are unique.) If the object file 
would fail to be unique even then, it can probably be safely declared 
the coder's fault for using a stupid naming scheme.

-- 
Kirk McDonald
Pyd: Wrapping Python with D
http://pyd.dsource.org