On Friday, 12 May 2017 at 02:43:17 UTC, evilrat wrote:
I use just dub and generated Visual D project.
Well in my case the problem is that engine is built as static
lib, and there is not much i can do with this. I've started
moving things around and turn lib to executable, at least now
build time cut in half, down to 20-22 sec.
And speaking about build time i mean exactly it, compile+link.
Compiling without linking is just 10-12 sec. That's really good
for single-threaded build!
Ah okay. If I understand correctly, the "game" itself is just the
two .d files in the Scripts folder, which get compiled then
linked with the prebuilt .lib for the engine. If so, a 10-12s
compile just for those two files still sounds really long to me.
Either I'm misunderstanding, or there's something bizarre going
on that's causing those build times.
I'm using derelict heavily in my project, and therefore most of
my libraries live in DLLs. I've run into some annoyances with
this, for example, bugs in the derelict interface to the DLL,
either existing ones or ones I introduce myself, can be very
difficult to detect and debug, since there's no type checking
across the DLL boundary. But one huge advantage is that the build
time overhead for these libraries is almost zero.
Everything I said about debugging was related to D, and on
Windows Visual D specifically.
C++ had it for ages.
Ah, my apologies I misunderstood. Agreed, the current debugging
experience for D leaves much to be desired unfortunately.
I see. This could even be benefit for low-level stuff like
renderer or physics system, especially when keeping required
data in large single array. But for the game part itself this
is no go, not for business at least.
Yeah I agree that this limitation sucks. Even if I try to avoid
using classes, there are still times where I'm forced into it.
For example, Thread is a class. I have to be very cautious when
working with an instance of Thread, or I risk bizarre crashes due
to mismatched typeinfo.
