dmd out of memory compiling vibed project

H. S. Teoh hsteoh at quickfur.ath.cx
Wed May 22 17:42:45 UTC 2019


On Wed, May 22, 2019 at 05:23:19PM +0000, Guillaume via Digitalmars-d wrote:
> On Wednesday, 22 May 2019 at 16:23:30 UTC, H. S. Teoh wrote:
> > On Wed, May 22, 2019 at 12:49:56PM +0000, Guillaume via Digitalmars-d
> > wrote:
> > > Hi,
> > > 
> > > I'm using dmd 2.086.0 and vibe.d 0.85.0 to compile a vibe.d
> > > project with ~20 views (*.dt). On my main computer, I have no
> > > problems but my laptop has only 4 gig of RAM and dmd is killed
> > > before the end of the compilation because it takes more than 4 gig
> > > of RAM.
> > > 
> > > I've tried the new -lowmem switch (in DFLAGS in dmd.conf) but it
> > > doesn't change anything. It does work with the "singleFile" option
> > > with dub but it's really long to compile... And the "singleFile"
> > > option seems to recompile everything even if I only change one
> > > ".d" source file.
> > [...]
> > 
> > Use separate compilation. (I don't know if dub support this.)
> > 
> 
> You mean compiling each file to create .o and then linking them? dub
> supports this with the "singleFile" option but recompiles everything
> each time. What tool do you use to automate compilation and linking?
[...]

IME, dub is useful as a packaging tool but not so much as a build tool.
Because of that I have given up on using dub as a build tool, and only
use it for pulling in dependencies.  For builds, I use SCons, though you
really could any general build system that isn't crippled. Even
Makefiles can do it, despite Make's many issues.

Whichever build system you choose, you don't really have to compile
*individual* files; you can compile clusters of them into static
libraries (the usual recommendation is one static library per package,
but that's only a convention; you can break it up however is most
advantageous for you), then link them together into the final
executable.

For example, for my vibe.d project I split up the source files into one
group for backend logic, then a group for base pages (front page and a
few other common "utility" pages), another group for creating new
accounts, and another group for the main functionality pages. In theory
I could also break up the backend logic into multiple groups, but IME
Diet templates take long enough to compile that that's not really the
bottleneck, so I left it as a single group for the time being.

Be warned, however, that you'll have to dig into some dirty details of
how dub works if you decide to go to go this route -- e.g., you may have
to parse dub output in order to get import paths, the list of object
files to link into the final executable, etc..  It's all scriptable once
you figure it out, of course, but you do have to get your hands dirty
once.


T

-- 
Give me some fresh salted fish, please.


More information about the Digitalmars-d mailing list