[kris]

When using the dmd compiler, all object files are placed into one directory. With really large projects, it's quite easy to end up with two files of the same name ~ whereupon one object file silently overwrites another and the link fails with a mysterious message.

One can try to use the -od switch, but that just changes the location where all those files are written (and fails if the directory does not exist).

We need a way to retain coherence between object files and the packages they belong to. One might consider prefixing the package-name onto the objectfile name?

Perhaps a better solution would be for a tool to create a subdirectory (perhaps two: one for build and one for debug) within each package involved, invoke the compiler for each said package, and construct an indirect "input file" for the linker to tell it where all the appropriate files are.

Something like that would be truly helpful.

[Derek Parnell]

I believe the -op switch on the DMD command line causes each object file to be created in the same directory as its source file.

Build always uses the -op switch. This means that object files are not always ending up in the same directory.

Does this help?
_________________
--
Derek
skype name: derek.j.parnell

[kris]

[Derek Parnell]

[kris]

OK; Build does the "right" thing in terms of isolating namespaces. Thanks.

I have another request: the -nounittest can get in the way when using 3rd-party classes. That is ~ unless you first compile the 3rd-party into a .lib (or whatever) you can easily end up with a bunch of 3rd-party unittests running instead of your own.

I understand the model you're following with Build, but then dmd is so damn fast that it's actually easier for the user to avoid the "build the library first" step, have Build figure out all the dependencies, and just compile the whole thing.

Specifically; compiling mango.example.Servlets with a -full and -clean takes about a second -- that includes compiling most of Mango too.

I also understand the conflict therein: how does one get their own unittest running without also tripping the 3rd-party ones too? The obvious answer would be for the user to take a two-stage approach, and compile the 3rd party into a lib first (where 3rd-party could mean the person sitting next to you, or perhaps some of your own, older, code).

It's just that this is not so convenient, and there just might be a better way? I'm bringing this up to prompt some thought on the subject, and to tentatively suggest the enabling of unittest is perhaps not the best default state?

That is, without unittest, you get the executable and nothing but the executable. If you /do/ want unittest, then there are potentially some considerations to make regarding 3rd-party software. Making the user 'think' should perhaps not be the default?

- Kris

[Derek Parnell]

[kris]

Ah ~ good on ya mate. Reckon I owe you a frothy one.