Suggestion: Object filenames should be fully-qualified module names

[Johan Granberg]

Kirk McDonald wrote:

> 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.
> 

I very much agree that something must be done and this solution is as good
as any.