I have this game engine...

[Johannes Pfau via Digitalmars-d]

Am Mon, 2 Nov 2015 14:22:33 +1000
schrieb Manu via Digitalmars-d <digitalmars-d at puremagic.com>:

> On 2 November 2015 at 04:17, Johannes Pfau via Digitalmars-d
> <digitalmars-d at puremagic.com> wrote:
> > Sounds like a great idea!
> >
> > I can certainly build the GDC toolchains*. But I guess the first
> > thing you'll need if you want to use Dreamcast, NDS and other low
> > memory systems is a @nogc druntime port? I had a look at this some
> > time ago and there's some work to be done until we can build a
> > druntime completely without GC.  
> 
> Awesome! Your support on this is really encouraging. Almost all
> consoles are typically targeted by GCC. PS4 uses Clang officially, but
> I'm sure GCC works just as well.
> 
> Easiest to start with some of the bigger systems. I think another
> benefit of this project may be that building for the smaller systems
> will start to reveal binary size issues, and perhaps we can use it as
> a vessel to drive some improvements in that area. Binary size is
> something that's been really irk-ing me for years.
> 
> What implicitly linked parts of druntime are not @nogc?

The usual stuff: AA handling, array concatenation etc. It's not a
problem as long as you don't use these. But to build a druntime without
the GC we'd have to find all these cases and place them in a
version(GCAvailable) block. If we build the GC stub or the GC we don't
have this problem.

Then there's some Exception handling related stuff: IIRC the backtrace
data is allocated using the GC and I think core.demangle uses the GC
as well. Probably not a big issue. 

Some higher level stuff such as Threads and Fibers also have special GC
integration. And then there are probably some 'toString' methods every
so often.

> I have no good reason to say that @nogc should be an absolute
> requirement... it is almost certainly preferable to many gamedevs so
> it would be nice to support it, but GC should be available if the
> developer wants it... I'm not sure what cost that comes at in terms of
> binary size. Runtime memory is a matter for the developer, they know
> the compromise they are making if they opt to use the GC.
> 

Maybe I'm a little to pessimistic about the GC ;-) I'm just not sure if
it can deal with low-memory situations such as if you've only got 16MB
memory total. And IIRC the GC always preallocates some blocks. So even
if we never use the GC it might steal some memory. OTOH it would
likely be not much work to adjust this allocation size.

> 
> > or better: also provide build scripts. We now use docker.io
> > containers to build the binary GDC toolchains. Building a toolchain
> > with the latest GDC version is as simple as running one docker
> > command:
> >
> > docker run
> > -v ~/shared-dir/:/home/build/shared #results will be saved here
> > -t jpf91/build-gdc /usr/bin/build-gdc build
> > --toolchain=x86_64-w64-mingw32/gcc-5/x86_64-w64-mingw32
> >
> > It should be easy enough to add support for console toolchain build
> > scripts.  
> 
> Awesome, and that would just be run along with the rest of the CI when
> producing toolchains? Reliable binary downloads available in known
> places?

These toolchains would be built like all other toolchains on
gdcproject.org/downloads and would also be listed on that page. 

We currently do not have a CI setup for all these toolchains. Building
the windows variant of a toolchain can take up to an hour (on my i5
notebook). Building all combinations for every commit on CI would be
very costly.

I hope to integrate all linux hosted toolchains with Travis-CI
(as a bonus we can probably extract nightly builds). It's a bit of a
PITA as building requires quite some disk space (10GB+ required,
semaphoreCI offers only 5GB). And I have to avoid these stupid
10 minute command timeout on travis-ci.

Let's see if this works:
https://travis-ci.org/jpf91/GDC/builds/88839377
(seems to be quite slow though...)

OTOH even if we manage to integrate CI this tests only that the code
builds. I don't think runtime testing is possible in some easy way.

> Even the presence of these toolchains (whether people use them
> or not) will inspire some confidence in gamedev's that D means
> business in gamedev. They are more likely to give D a shot if they
> know that toolchains are available should ports need to be made at
> some later stage.