February 23, 2012
On Wednesday, February 22, 2012 16:08:20 H. S. Teoh wrote:
> 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.

Yuck. Yuck. Source should _always_ be separated from object files. It's incredibly messy otherwise.

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

That's definitely the way to organize things.

- Jonathan M Davis
February 23, 2012
Although I agree that sources and objects should be sperated there are some
benifits.  All tools know where to look for the objects.  And is not
dificult to keep out of scm.  A great example of this is Haskell.  To
compile an app you only need to specify the main file and it finds all the
included modules, only recompiling if nessary.  And if I remember correctly
it also spits out a "definition list" type file that is great for things
like code completion.
On Feb 22, 2012 7:15 PM, "Jonathan M Davis" <jmdavisProg@gmx.com> wrote:

> On Wednesday, February 22, 2012 16:08:20 H. S. Teoh wrote:
> > 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.
>
> Yuck. Yuck. Source should _always_ be separated from object files. It's incredibly messy otherwise.
>
> > Either that, or duplicate the source tree structure in an object tree (if you like that kind of compile structure -- some projects do that).
>
> That's definitely the way to organize things.
>
> - Jonathan M Davis
>


February 23, 2012
On Wed, Feb 22, 2012 at 07:15:37PM -0500, Jonathan M Davis wrote:
> On Wednesday, February 22, 2012 16:08:20 H. S. Teoh wrote:
[...]
> > 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.
> 
> Yuck. Yuck. Source should _always_ be separated from object files. It's incredibly messy otherwise.

Not really. You just have .d's with their corresponding .o's sitting side-by-side. It's a 1-to-1 correspondence. No mess.


> > Either that, or duplicate the source tree structure in an object tree (if you like that kind of compile structure -- some projects do that).
> 
> That's definitely the way to organize things.
[...]

To each his own. :)

But either way, the point is that the source tree structure *must* be reflected by the object files. Otherwise you break the 1-to-1 correspondence and all sorts of nasty bugs show up.


T

-- 
It only takes one twig to burn down a forest.
February 23, 2012
On Wednesday, February 22, 2012 16:28:45 H. S. Teoh wrote:
> On Wed, Feb 22, 2012 at 07:15:37PM -0500, Jonathan M Davis wrote:
> > Yuck. Yuck. Source should _always_ be separated from object files. It's incredibly messy otherwise.
> 
> Not really. You just have .d's with their corresponding .o's sitting side-by-side. It's a 1-to-1 correspondence. No mess.

I would consider the fact that they're in the same folder to be a mess in and of itself even without going into the other pros and cons, but there's no point in getting in an argument about it.

> But either way, the point is that the source tree structure *must* be reflected by the object files. Otherwise you break the 1-to-1 correspondence and all sorts of nasty bugs show up.

Definitely.

- Jonathan M Davis
February 23, 2012
On Wed, Feb 22, 2012 at 09:36:12PM -0500, Jonathan M Davis wrote:
> On Wednesday, February 22, 2012 16:28:45 H. S. Teoh wrote:
> > On Wed, Feb 22, 2012 at 07:15:37PM -0500, Jonathan M Davis wrote:
> > > Yuck. Yuck. Source should _always_ be separated from object files. It's incredibly messy otherwise.
> > 
> > Not really. You just have .d's with their corresponding .o's sitting side-by-side. It's a 1-to-1 correspondence. No mess.
> 
> I would consider the fact that they're in the same folder to be a mess in and of itself even without going into the other pros and cons, but there's no point in getting in an argument about it.
[...]

You're entitled to your opinion. :) I just prefer to keep things in one place if there's no confusion caused.


T

-- 
IBM = I Blame Microsoft
February 23, 2012
On 2012-02-22 22:37, 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

I've tried to implement that several times but something always fails on Windows.

-- 
/Jacob Carlborg
February 23, 2012
Am 23.02.2012 00:03, schrieb Jonathan M Davis:
> 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

Am I not seeing something obvious in this discussion, or is there something that "dmd -op -c ..." or "dmd -odobj -op -c ..." would do wrong?
February 23, 2012
On 2012-02-22 23:42, Brad Roberts wrote:
> 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.

Yeah, sorry, my bad.

-- 
/Jacob Carlborg
February 23, 2012
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
February 23, 2012
On 2012-02-22 23:33, 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?

See my reply to Jonathan:

http://forum.dlang.org/thread/svyqjflmabsxabmnpzrg@forum.dlang.org?page=2#post-ji56kf:242j8p:241:40digitalmars.com

-- 
/Jacob Carlborg