Suggestion: Object filenames should be fully-qualified module names

Bradley Smith digitalmars-com at baysmith.com
Sat Jan 20 13:13:19 PST 2007


Have you seen issue 492 (http://d.puremagic.com/issues/show_bug.cgi?id=492)?


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



More information about the Digitalmars-d mailing list