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

Jonathan M Davis jmdavisProg at
Fri Feb 24 10:47:11 PST 2012

On Thursday, February 23, 2012 13:42:44 Jacob Carlborg wrote:
> On 2012-02-23 00:03, Jonathan M Davis wrote:
> > 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
> I don't see a point in putting the object files in different directories
> when the compiler can output the object files with fully qualified
> module names.

It organizes things better IMHO to have them in a separate directory hierarchy 
which matches the source's directory hierarchy, but outputing modules with 
fully qualified modules names does solve the core problem as long as it can be 
done in a manner that's not going to result in conflicts (which you've shown a 
way to do). A build tool can organize the object files differently if you want 
it to. Worrying about the directory structure is the sort of thing that's 
better left to a build tool anyway.

I was pointing out that I thought that using a separate directory structure is 
the ideal way to go and that the previous suggestion of renaming modules 
wouldn't work. The only remaining issue then is the fact that dmd is faster 
when compiling multiple modules at once, which ends up making it so that using 
a build tool to build each module separately to organize it how you want would 
result in a slower build. But that may just be the way that life goes.

- Jonathan M Davis

More information about the Digitalmars-d mailing list