Increasing Alignment

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.

  • fserb

    Does this mean that Lime will have a dependency on the low level part of NME?

    Are there plans to make NME less of a monolithic thing in the future?

  • Joshua Granick

    As a user, NME and Lime will both be choices as a “base layer” for development, with their own set of tools. There is no runtime dependency between Lime and NME.

  • Lars Doucet

    So basically this is a way for these similar-but-different projects to continue to share some code, but not be dependent on one another?

  • Joshua Granick

    Absolutely, we are working together to build a stable, mature native C++ implementation for Haxe projects, then we’re allowing both the NME and Lime projects to apply that implementation somewhat differently

  • Hugh Sanderson

    It depends what you mean by monolithic. NME will remain a single project, single NDLL, single haxelib so maybe no plans to make it less monolithic. But there might be some more interesting ways you can use only a part of it, or extend it.

  • Hugh Sanderson

    We are working hard to ensure that there is a single code base for all the internal stuff – which means that bug fixes need only be done in one place. Of top of this, there are the two systems – nme and lime/openfl, and the choice between this is mostly a question of taste. You could think of this as “make” vs “ant” – two different build systems, but they both use the same compiler and libraries at the end of the day.
    Where the two system differ, it is because of a desire to present something in a different way, where they are similar, they will now share exactly the same code. This way, there is not duplication.

  • Jeremy Sachs

    So did you guys hug? :-)