On Monday, 23 July 2018 at 08:08:03 UTC, Mike Franklin wrote:
So, IMO, if you need to link in a library or object file that
was not compiled from D code, then you're cheating. This is
also one of the reasons why I suggested re-implementing
software building blocks such as `memcpy`, `memset`, `malloc`,
`free`, etc. in D as another potential project for the Autumn
of Code.
So, to keep this software rasterizer project within scope, I
suggest creating naive implementations of those functions in D
for now to stay true to spirit of the project (no dependencies,
everything in D), and "make the point". You can those software
building blocks in their own module, and let the user of the
software rasterizer library link it their own implementation if
they wish to deviate from the spirit of the proposal.
That's actually what I am doing now. Currently I wrote a short
script to ensure the symbols in the main project within a subset
(https://github.com/htfy96/rasterizer-d-embed/blob/master/check-no-und-symbols.sh). I also plan to create some basic dependency-free building blocks like memcpy/memset/memcmp (already implemented in https://github.com/htfy96/d-rlib) and malloc/free (maybe reusing some building blocks from std.experimental.allocator?) in separate projects. Regarding floating point operations, I plan to use dmd.builtins/ldc.builtins instead of linking with libm.
Above this well-defined set of primitives, the core rasterizer
will be built, so that users can plug in their own
implementations or use the default implementation when libc/libm
is linked.
