dmd -c behaviour doesn't take account of packages.
Jonathan M Davis
jmdavisProg at gmx.com
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