Created attachment 514
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).
Comment #1 by nfxjfg — 2010-01-01T07:51:35Z
Created attachment 541
updated patch
Updated to dmd 1.054, if anyone cares.
Apply with "patch -p1 < patchfile" in dmd source directory.
Comment #2 by leandro.lucarella — 2010-01-01T11:32:36Z
Comment on attachment 541
updated patch
Marked as patch
Comment #3 by mpiepk — 2010-01-08T03:25:14Z
Created attachment 547
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"
Comment #4 by nfxjfg — 2010-03-29T16:17:40Z
What do I have to do to make dmd support -oq ?
Comment #5 by nfxjfg — 2010-05-01T12:00:35Z
Created attachment 618
updated patch for dmd 1.059 beta (~ svn 461)
this probably still crashes with win32 patch => not obsoleting mpiepk's patch
Comment #6 by nfxjfg — 2010-06-13T22:20:53Z
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.)
Comment #7 by nfxjfg — 2010-12-02T09:28:19Z
I'm updating this patch to new dmd versions all the time, just mail me if you're actually interested in it lol.
Comment #9 by andrej.mitrovich — 2011-03-26T17:05:48Z
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.
Comment #10 by bugzilla — 2011-05-28T12:27:44Z
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