
Sigbjorn:
Win32 library. SOE. HDirect generated COM client code + libraries. GC, as released, will output HugsAPI3 decls. HDirect outputs HugsAPI2.
I'd really like to kill off these dependencies so that we're just supporting one API and we know what we're free to change, what we have to test and so that we only have to support one API. So, I killed the Hugs backend for GreenCard since the ffi backend provides the same functionality. The CVS copy of HDirect uses API4 so it isn't affected by this commit but I'd like you to delete that backend anyway and have people switch over to the ffi backend. Win32 and SOE are known to build fine with the ffi backend so all we have to do is update documentation and do a fresh release. (I've got some pending changes for a new SOE release anyway.) So the only things left are previously generated HDirect COM code and any other previously generated GreenCard code. Is there that much? Is it that hard to regenerate? Will it still exist next time we do a Hugs release? Sigbjorn:
There's little cost in supporting it, hence my suggestion.
I'd like to make a serious effort to kill all the dependencies on the old code. If we reckon this isn't enough, I'm happy to revert the code and come back to this in a year or so and try again. You're right that it's not much code but there's a lot of cruft in Hugs and this seems like an easy place to start cutting.
I wouldn't mind simply having needPrims() treat 2&3 just like 4.
I'm not sure if that works - I made some changes in how Floats and Doubles are handled when I switched over to handling the ffi. -- Alastair