dmd -c behaviour doesn't take account of packages.

[Kevin Cox]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20120222/cacdf753/attachment.html>