On 2012-02-22 23:05, Jonathan M Davis wrote:
On Wednesday, February 22, 2012 22:33:35 Bernard Helyer wrote:
A discussion on the Mono-D IRC channel just made me realise
something.
dmd -c foo/a.d bar/a.d
The second module overwrites the first. This makes using 'pass
everything at once' with Mono-D (IDE plugin)
difficult/impossible. As far as I'm concerned, it's just a bug
that's never come up. The solution is trivial, of course. Prepend
package names so you get foo_a.o and bar_a.o. Either that or
allow specific output paths to be specified per-object.
Then what happens when you have
dmc -c foo/a.d foo_a.d
The way -oq works is the compiler uses the fully qualified name of the
module in the file name of the object file. So if foo/a.d has "module
foo.a;" and foo_a.d has "module foo_a;" then the following object files
will be created:
foo.a.o
foo_a.o
No conflict. If there would have been a conflict with the object files
,it would have been a conflict with the module names as well and the
compiler would have stopped before generating the object files.
Or just
produce one object file. Anything _but_ the current behaviour, in
fact.
Generating one object file would make far more sense.
If you're going to worry about modules when generating object files, then you
really should be putting the object files in the same directory layout as the
modules have. But that sort of thing is arguably a build tool's job, not the
compiler.
No I don't think so. If the compiler generate object file names based on
the fully qualified module name it will be A LOT easier to implement a
build tool that can do incremental builds. I don't see any advantage of
putting the object files in sub directories.
Regardless, I really wouldn't like the idea of screwing with the object file
names to try and avoid collisions. If anything, the compiler should complain
that
dmd -c foo/a.d bar/a.d
will result in a conflict, because one file would overwrite the other. But the
single object file solution sounds reasonable.
- Jonathan M Davis
--
/Jacob Carlborg
