Concern about dmd memory usage on win32

Jonathan M Davis jmdavisProg at gmx.com
Fri Dec 7 11:18:59 PST 2012


On Friday, December 07, 2012 20:04:54 Andrej Mitrovic wrote:
> On 12/7/12, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > Then I'd have two suggestions then:
> Actually there is one other way, use version specifiers and then
> re-compile using different versions, e.g.:
> 
> <line 1>
> version(StdAlgTest1)
> {
> <..lots of tests...>
> }
> 
> <line 1000>
> version(StdAlgTest2)
> {
> <..lots of tests...>
> }
> 
> <line 2000>
> version(StdAlgTest3)
> {
> <..lots of tests...>
> }
> 
> Then the makefile would have to compile algorithm.d 3 times, via something
> like:
> 
> $ rdmd --unittest -version=StdAlgTest1 --main std\algorithm.d
> $ rdmd --unittest -version=StdAlgTest2 --main std\algorithm.d
> $ rdmd --unittest -version=StdAlgTest3 --main std\algorithm.d
> 
> In fact, why aren't we taking advantage and using rdmd already instead
> of using a seperate unittest.d file? I've always used rdmd to test my
> Phobos changes, it works very simple this way. All it takes to test a
> module is to pass the --unittest and --main flags and the module name.

The windows build purposefully creates one executable in order to catch stuff 
like circular dependencies and to give dmd a larger project to compile at once 
in order to test dmd. Clearly, we're running into issues with that due to 
dmd's lack of capabilities when it comes to memory. But Walter has rejected 
all proposals to change it, and to some extent, I think that he's right. If
anything, this is just highlighting an area that dmd really needs to be
improved. All of the messing around that we've done with the makefiles is
just hiding the problem.

The POSIX builds do build the modules separately for unit tests, though they 
don't use dmd. I would point out though that as it stands, it wouldn't work to 
use rdmd, because it's in the tools project and not in dmd, druntime, or 
Phobos. Rather, it depends on them, so they can't depend on it.

- Jonathan M Davis


More information about the Digitalmars-d mailing list