On a whim, I sat down with a copy of my working copy of Derelict today to get a feel for Derelict2. Particularly, I wanted to see how things look after the merging of some packages and to get an idea of how difficult it will be to modify the source for D2 support. It took very little time, much less than I expected, to get to the point where I had a compilable code base that supports both D1 and D2 (though I temporarily removed Tango support) out of the box. It compiles, it links, and my simple little tests work fine with D1 and D2. On top of that, the condensed source tree is much, much nicer to look at (and to work with!). Unfortunately, things never really are that easy.
While the code works as-is, the library interfaces are almost certainly going to have to be modified. toStringz in D2 returns a const(char)*, whereas the function prototypes in Derelict that take C strings, being that they are bound to C libraries, expect plain old char*. It will get mighty tedious mighty fast having to cast every call to toStringz to lose the const. I got around this internally in Derelict by casting to char* before returning from the toStringz wrapper in DerelictUtil. So I could recommend that Derelict users make use of that version — it will do the right thing between D1/D2 and Phobos/Tango (once I add Tango support back in) and leave it at that. But, realistically, that’s just not going to work. So for full D2 support I’ll need to modify the bindings in every package where appropriate.
A more critical problem is that DerelictFT fails to compile with the latest D2 (not tried previous versions). It still works fine with D1, but D2 keeps barfing with assert failures by the compiler. Specifically:
compile dmd -c derelict\freetype\ft.d -ofdsss_objs\D\derelict-freetype-ft.obj
-IC:/dev/D/dsss/bin\..\include\d -Idsss_imports\ -I. -L-L.\ -IC:\dev\D\ds
ss\include\d -L-LC:\dev\D\dsss\lib\ -IC:\dev\D\dsss\include\d -L-LC:\dev\D\ds
ss\lib -I../DerelictUtil -IC:\dev\D\Mars\D2\dmd\bin\..\src\phobos -IC:\dev\D\
Mars\D2\dmd\bin\..\src\druntime\import
Assertion failure: ‘t->deco’ on line 604 in file ‘mtype.c’
abnormal program termination
compile dmd -c derelict\freetype\ftfuncs.d -ofdsss_objs\D\derelict-freetype-f
tfuncs.obj -IC:/dev/D/dsss/bin\..\include\d -Idsss_imports\ -I. -L-L.\ -IC
:\dev\D\dsss\include\d -L-LC:\dev\D\dsss\lib\ -IC:\dev\D\dsss\include\d -L-LC
:\dev\D\dsss\lib -I../DerelictUtil -IC:\dev\D\Mars\D2\dmd\bin\..\src\phobos -
IC:\dev\D\Mars\D2\dmd\bin\..\src\druntime\import
Assertion failure: ‘t->deco’ on line 604 in file ‘mtype.c’
abnormal program termination
compile dmd -c derelict\freetype\fttypes.d -ofdsss_objs\D\derelict-freetype-f
ttypes.obj -IC:/dev/D/dsss/bin\..\include\d -Idsss_imports\ -I. -L-L.\ -IC
:\dev\D\dsss\include\d -L-LC:\dev\D\dsss\lib\ -IC:\dev\D\dsss\include\d -L-LC
:\dev\D\dsss\lib -I../DerelictUtil -IC:\dev\D\Mars\D2\dmd\bin\..\src\phobos -
IC:\dev\D\Mars\D2\dmd\bin\..\src\druntime\import
Assertion failure: ‘t->deco’ on line 604 in file ‘mtype.c’
abnormal program termination
compile dmd -c derelict\freetype\sftfuncs.d -ofdsss_objs\D\derelict-freetype-
sftfuncs.obj -IC:/dev/D/dsss/bin\..\include\d -Idsss_imports\ -I. -L-L.\ -
IC:\dev\D\dsss\include\d -L-LC:\dev\D\dsss\lib\ -IC:\dev\D\dsss\include\d -L-
LC:\dev\D\dsss\lib -I../DerelictUtil -IC:\dev\D\Mars\D2\dmd\bin\..\src\phobos
-IC:\dev\D\Mars\D2\dmd\bin\..\src\druntime\import
Assertion failure: ‘t->deco’ on line 604 in file ‘mtype.c’
abnormal program termination
Command C:\dev\D\dsss\bin\rebuild.exe returned with code 1, aborting.
Error: Command failed, aborting.
I imagine this is going to take some effort to narrow down to a minimal case for a bugzilla report. I’ll get around to it.
At any rate, since this is turning out to be less of a headache than I thought it would be (DerelictFT issues aside), I’m going to go ahead and create a Derelict2 branch in the next few days and start cracking. That will also help get more eyes on the DerelictFT problem. I had initially intended to tag the current trunk and just do Derelict2 dev in the trunk. That’s really not the way to go, though, since most Derelict users rely on the trunk to actually work. So I’ll do all Derelict2 dev in a branch and merge it to the trunk later on down the road. Since it’s not going to be an issue supporting both D1 and D2, I don’t see any reason why (what-will-soon-be) the old Derelict need hang around any longer than necessary.
So I’ll be working on this in fits and spurts over the coming weeks and months. I’ll announce here when the new branch is ready so that any of you wanting to play with it can. Aside from the DerelictFT issue with D2, it should be quite usable almost as soon its committed. But I make no promises as to its continued stability. I’ll be updating and making changes over the coming weeks and months. I’ll try not to make any breaking changes if I can reasonably avoid it. I would like to ensure that all current Derelict clients continue to compile without change. But there may be a few minor nits.
In the meantime, I’m still open to suggestions and ideas about where to take Derelict 2. If you have any, please head over to the Derelict forum and post them in the suggestion thread.
Technorati Tags: D Programming Language, Derelict
from Amazon.