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