There have been some concerns recently about hxcpp and hxlibc, and Lime and NME, regarding fragmentation in the Haxe community.
I hope I can help address some concerns, we feel that alignment within the Haxe community is better for everyone, so long as the goals are the same.
hxcpp is the standard Haxe C++ support library. OpenFL (as you may also know) is distributed by haxelib, which means we were bound to the hxcpp release cycle, which was about every year. A lot can change in that time.
I used to solve this by adding an unreleased version of hxcpp in the all-in-one NME installers. Personally, I believe it would be good for haxelib to support multiple repository sources, this way, a user could subscribe to “beta” or “development” channels for their libraries, or an OpenFL user could receive a newer library if needed.
That was the first problem, but we are working to get hxcpp tested and released more often.
There are other, vital reasons why we created hxlibc, but in a future release, we hope to move to hxcpp by default again. We have already done this in the development builds, and believe that the new hxcpp is better than the older hxccpp or hxlibc before.
OpenFL was created out of the NME project, NME walked a line between “like Flash” and “not quite like Flash” that OpenFL sought to change — by taking a bold step, and committing to compile Haxe/Flash applications to new platforms, we believed that the utility of the NME project would increase. We are very, very happy with the success of the OpenFL project.
In the background, NME was actually still around. For the first six months, commits were going into NME almost daily, until we reached a point where it felt we were moving in two different directions.
With the Flash API emphasis that was created with OpenFL, we wanted to invest in a “generic” API to enable multiple Haxe frameworks to support all the same platforms, with the same tools. We had the vision for an “SDL for Haxe,” to provide a stable base layer for many Haxe projects to target native platforms, using new or alternative APIs.
It was made clear that this was not the vision for the NME project, so we reluctantly decided to move the native code out of NME, and into Lime directly.
Our vision for Lime is to create an open collaboration, where developers can help build a stable foundation for Haxe native projects, with a common set of tools and simple support for every platform.
The vision for Lime remains the same, but we are finding new ways to collaborate between Lime and NME to promote a more stable and robust environment for each project.
In the next Lime release, I believe we will be working from a new, shared C++ codebase. In order to preserve the long history of our collaboration in building this code together, we have decided to use the NME repository as the home for this code.
Lime will use its own NDLL, just as it does now, so Lime and NME will remain separate projects. Where they are in common, NME and Lime will both benefit from the relationship, such as a specific platform fix or improvements to the renderer performance. Lime will still retain the new Android extension system we introduced, and will continue to use OpenAL audio instead of SDL_mixer. We are working together to plan on refactoring the shared codebase and to look for more ways to align where it supports the goals of both projects.
As a user, Lime, OpenFL and your development environment will remain stable, but we’re doing what we can at a code collaboration level to find where can eliminate immaterial differences and work with even more collaborators.