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. Or just produce one object file. Anything _but_ the current behaviour, in fact.

On Wednesday, 22 February 2012 at 21:33:36 UTC, Bernard Helyer wrote:
>     dmd -c foo/a.d  bar/a.d
>
> The second module overwrites the first.

-oq, anyone? ;)

David

On Wednesday, 22 February 2012 at 21:36:10 UTC, David Nadlinger wrote:
> -oq, anyone? ;)

Whoops, forgot the link: https://github.com/D-Programming-Language/dmd/pull/563.

David

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

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

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

On Wednesday, 22 February 2012 at 22:05:51 UTC, Jonathan M Davis wrote:
> Then what happens when you have
>
> dmc -c foo/a.d foo_a.d
>

Good point.

>
> Regardless, I really wouldn't like the idea of screwing with the object file
> names to try and avoid collisions.

Well, the thing is in this case everything is being passed to the compiler. It knows the names of everything. But yeah, I think complaining is fine _if_ dmd allows individual modules to be named explicitly. Otherwise, all in one is good. But really, even prefixing it would be better than what we have now. What about 'module.foo_a.o' if foo_a isn't in a package?

On Wed, 22 Feb 2012, David Nadlinger wrote:

> On Wednesday, 22 February 2012 at 21:36:10 UTC, David Nadlinger wrote:
> > -oq, anyone? ;)
> 
> Whoops, forgot the link: https://github.com/D-Programming-Language/dmd/pull/563.
> 
> David

If only one of the attempts to implement that option actually worked.

On Wednesday, February 22, 2012 23:33:57 Bernard Helyer wrote:
> On Wednesday, 22 February 2012 at 22:05:51 UTC, Jonathan M Davis
> 
> wrote:
> > Then what happens when you have
> > 
> > dmc -c foo/a.d foo_a.d
> 
> Good point.
> 
> > Regardless, I really wouldn't like the idea of screwing with
> > the object file
> > names to try and avoid collisions.
> 
> Well, the thing is in this case everything is being passed to the compiler. It knows the names of everything. But yeah, I think complaining is fine _if_ dmd allows individual modules to be named explicitly. Otherwise, all in one is good. But really, even prefixing it would be better than what we have now. What about 'module.foo_a.o' if foo_a isn't in a package?

I really think that it should either put it in a single object file or complain and disallow it. Really, the correct way to build such modules is to put each object file in a directory hierarchy which matches the modules. Anything else is a mess. But that's the job a build tool, not the compiler. So, it should do what's reasonable, which doesn't include renaming files to avoid module collisions IMHO.

- Jonathan M Davis

On Wednesday, 22 February 2012 at 22:44:15 UTC, Jonathan M Davis wrote:
> On Wednesday, February 22, 2012 23:33:57 Bernard Helyer wrote:
>> On Wednesday, 22 February 2012 at 22:05:51 UTC, Jonathan M Davis
>> 
>> wrote:
>> > Then what happens when you have
>> > 
>> > dmc -c foo/a.d foo_a.d
>> 
>> Good point.
>> 
>> > Regardless, I really wouldn't like the idea of screwing with
>> > the object file
>> > names to try and avoid collisions.
>> 
>> Well, the thing is in this case everything is being passed to the
>> compiler. It knows the names of everything. But yeah, I think
>> complaining is fine _if_ dmd allows individual modules to be
>> named explicitly. Otherwise, all in one is good. But really, even
>> prefixing it would be better than what we have now. What about
>> 'module.foo_a.o' if foo_a isn't in a package?
>
> I really think that it should either put it in a single object file or complain
> and disallow it. Really, the correct way to build such modules is to put each
> object file in a directory hierarchy which matches the modules. Anything else
> is a mess. But that's the job a build tool, not the compiler.

Except DMD is faster by a factor of 10 when passing it all at once.

On Wednesday, February 22, 2012 23:50:53 Bernard Helyer wrote:
> Except DMD is faster by a factor of 10 when passing it all at once.

Then maybe there _should_ be a flag to tell it to use/generate the appropriate directory structure. You already typically give it an output directory. It wouldn't be all that hard for it to then generate and use the correct directories in that directory. That still bugs me a little, because that's more of a build tool's job, but it wouldn't be hard to do, would fix the file conflicts across modules, and would let you keep that extra speed.

- Jonathan M Davis

On Wed, Feb 22, 2012 at 05:05:40PM -0500, 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.
[...]

The real solution is that when creating object files, dmd should put the .o files in the modules' respective subdirectories. I.e., it should keep the pathname component of every source file and use that for the object file. Then you have a 1-to-1 mapping between source files and object files.

Either that, or duplicate the source tree structure in an object tree (if you like that kind of compile structure -- some projects do that).

Everything else is just a hack and prone to errors.


T

-- 
My program has no bugs! Only unintentional features...