When passing absolute paths to dmd, compiling with -op and -od will make dmd write the object file into the same directory as the source file. But it really should write somewhere inside the directory passed by -od.
Demonstration:
cd /tmp/x/
dmd -op -od/tmp/x/ /tmp/test/foo.d
# dmd creates /tmp/test/foo.o
# it really should crate it somewhere under /tmp/x/
# (maybe /tmp/x/tmp/test/foo.o ?)
This makes -op and -od utterly useless for build scripts or any other advanced use. Actually, it makes dmd look like dirtying include directories, and you have to manually clean up them.
What is the point of -od, when dmd decides to write the object files somewhere else anyway? It doesn't make any sense, thus it must be a bug.
Note that build scripts can not use -od without -op: modules with same name (but different packages) will map to the same filename. E.g. modules a.foo and b.foo will both map to foo.o, and dmd will simply overwrite one of these files, leading to missing symbols in the linker stage.
Comment #1 by nfxjfg — 2010-04-15T18:00:36Z
Note that ldc supports the -oq switch, which is much more friendlier to build scripts. Bug 3541 has a patch to enhance dmd with -oq. In combination with -deps, -oq uses object filenames that can be easily known by build script, instead of having to emulate dmd's path handling to find out the final object filename.
E.g. in the example above, where should foo.o really be written? The filename/path must not clash with other modules named "foo", and using the package name seems the simplest solution. Which is exactly what -oq does.
Further note that the only properly working build tool for D, xfbuild, uses incredible kludges to work this around. When there are modules with the same name/different packages, it does several compile runs to avoid dmd overwriting the object files it just created in the same run.
I hope this is motivation enough to solve this problem "upstream".
Comment #2 by nfxjfg — 2010-04-15T18:06:07Z
I have to add that this doesn't really only apply to absolute paths. Relative paths to source files exhibit similarly messed up behavior, but I'm not really sure why or what it actually does or is supposed to do. It's something for a separate bug report.
Comment #3 by nfxjfg — 2010-12-02T09:43:39Z
As of dmd 1.065, the behaviour seems to be slightly different. Anyway, it still doesn't work. dmd keeps overwriting its own object files if there are modules with same name from different packages.
Comment #4 by nfxjfg — 2010-12-02T10:16:51Z
(In reply to comment #3)
> dmd keeps overwriting its own object files if there are modules
> with same name from different packages.
Scratch that, up on closer inspection, the problem is exactly the same as described in the initial comment.
Comment #5 by turkeyman — 2013-07-31T15:08:38Z
This is still a problem...
VisualD makes use of this extensively, which causes lots of problems.
Plz can haz fix? :)
Comment #6 by andrej.mitrovich — 2013-07-31T15:13:50Z
(In reply to comment #1)
> Note that ldc supports the -oq switch, which is much more friendlier to build
> scripts. Bug 3541 has a patch to enhance dmd with -oq.
It also has a pull, but it needs more votes: https://github.com/D-Programming-Language/dmd/pull/1871
Comment #7 by andrej.mitrovich — 2013-07-31T15:14:41Z
Btw why is this tagged as only D1, doesn't it affect D2 as well?
Comment #8 by turkeyman — 2013-07-31T15:17:53Z
I guess it's just ancient ;)
Comment #9 by robert.schadek — 2024-12-13T17:52:04Z