Created attachment 514 [details] patch for dmd 1.051 to add -oq This patch adds the -oq option to dmd. When dmd is invoked with -oq, it uses the fully qualified module name for the filename. E.g. when a module contains the module declaration "module foo.moo.huh;", the file is output as "foo.moo.huh.o". Why is -oq a good idea? Right now, build tools can use -od, but if there are modules with the same names in different packages, clashes occur. You could use -op to avoid this, but then object files will be all over the user's source tree (which sucks, especially if dmd and/or the build tool crash, and leave the object files everywhere). LDC had this option since ages, and I think it's time that dmd also knows it. Further remarks: - The option respects the -od option. - An error is raised when a module doesn't contain a ModuleDeclaration (this is intentionally). - dmd creates the filenames in the Module ctor; this is a problem because the module declaration is needed to compute the object filename. I had to change it and move the code to somewhere after Module.parse() is invoked. - As a result, I'm not quite sure if I introduced regressions with the plenty of other output methods. - I hope the option is LDC compatible (xfbuild was able to use the patched dmd with -oq).
Created attachment 541 [details] updated patch Updated to dmd 1.054, if anyone cares. Apply with "patch -p1 < patchfile" in dmd source directory.
Comment on attachment 541 [details] updated patch Marked as patch
Created attachment 547 [details] Updated patch The old patch contained inconsistent line endings and crashed patch (at least on Win32). This also removes the "feature" that dmd strips the ".lib"/".obj" file extension when building the linker command line (link.c), because it would fail for filenames like "package.module.obj"
What do I have to do to make dmd support -oq ?
Created attachment 618 [details] updated patch for dmd 1.059 beta (~ svn 461) this probably still crashes with win32 patch => not obsoleting mpiepk's patch
For dmd 1.062, watch out for the comment "// Bugzilla 3547" in module.c: you have to move my changes into the indented new indented else branch. Not bothering with a real updated patch, line ending issues make this kind of infeasible, and Walter probably applies patches manually anyway. (Plus he obviously isn't interested in this.)
I'm updating this patch to new dmd versions all the time, just mail me if you're actually interested in it lol.
Pull request available: https://github.com/D-Programming-Language/dmd/pull/11
Interesting. Currently I have a very superficial D build script which simply creates a ./cache folder, recreates the folder structure of the source tree inside this cache folder, and puts object files and library files there by simply using -of via DMD. So for example the source tree is: ./main.d ./bar/all.d ./bar/barclass.d ./foo/utils.d And the generated files would be: ./cache/bar/bar.lib ./cache/bar/all.obj ./cache/bar/barclass.obj ./cache/foo/foo.lib ./cache/foo/utils.obj Then I have no conflicts. But its very artificial as the build script was done in one afternoon.
The patch crashes on line 254 of module.c when compiling druntime with the line: ..\dmd.exe -c -d -o- -Isrc -Iimport -Hfimport\core\atomic.di src\core\atomic.d
See also https://github.com/D-Programming-Language/dmd/pull/169
New pull request: https://github.com/D-Programming-Language/dmd/pull/563
https://github.com/D-Programming-Language/dmd/pull/1871