On 19.03.2017 13:16, Mike Parker wrote:
Every few years I do a little test to see how much effort it takes to
get the ioquake3 [1] codebase set up in a way that I can replace bits of
it with D implementations and compile it all together. Not because I
plan to port the whole thing, but I'm perennially curious how difficult
it would be for someone to get started on porting a complex C project to
D piece by piece (the way it should be done). I have to say, Rainer has
made it easier than ever on Windows with the new Visual D release [2].
So I generated a VS 2015 solution with the ioq3-premake-msvc project
[3], loaded it up, compiled it all to make sure it works (ioq3 will find
the Quake3 resources automatically if you have Quake3 installed via
Steam). Then I added a D file, picked a function to reimplement in D,
and built it again. This resulted in a handful of linker errors because
the runtime isn't linked in automatically. Once I opened up the project
properties and added the path to dmd2/windows/lib32mscoff to the linker
directories and phobosm32mscoff.lib to the linker input, I had an
instance of Quake3 running with a D implementation of Sys_Milliseconds [4].
As easy as that. No writing up custom build scripts, no manually adding
D object files to the ioq3 project, or any of the other approaches I've
taken in the past. Awesome! I think I'll do a write up on this for the D
blog in the near future.
Great job, Rainer!
[1] https://ioquake3.org/
[2] http://forum.dlang.org/thread/oa3dp7$icu$1...@digitalmars.com
[3] https://github.com/jpcy/ioq3-premake-msvc
[4] http://i.imgur.com/VP0ibfH.png
Thanks for the report, Mike.
Having to add the phobos library and the search path should only be
necessary, if the D files are added to a static library project, and
none is added to the project that actually links the binary. I hope that
this was the case for Quake, but your screen shot suggests otherwise.
