COMMUNITY

Gathering Native Extensions


(Joshua Granick) #1

Hello! We are working to galvanize efforts to build native extensions in the Haxe community. If you have extensions or are interested in contributing to supporting, building or making new standards for extensions, let me know :slight_smile:

Here’s the current team page on Github, open to different team names, too, if you guys think another would be better :slight_smile:

There are plans to add nightly builds for extensions that require binaries to be built, as well other work to keep things up to date


#2

Shouldn’t they be called “OpenFLExtensions” instead of “HaxeExtensions”. Browsing it a bit I did not see a single one, which is not depending on OpenFL


(Joshua Granick) #3

We want to help forward the goal of building extensions for Haxe frameworks. Getting extensions that work for Lime and OpenFL is a step in that direction. Happy to work with anyone who is using different Haxe frameworks in production, who want to help contribute to broaden the scope so that the extensions support multiple frameworks at once :slight_smile:


(saumya) #4

Well, I am not sure whether my extensions for Android are qualified for this.

Here is the list

Thanks @singmajesty for this effort. A much needed one.


(Joshua Granick) #5

@saumya I sent you an invite, you’re welcome to share them! It might be good to rename them (following the “extension-*” convention) but otherwise, your contributions would certainly be appreciated :slight_smile:


(Jérémy Faivre) #6

Following up on this subject,

It’s a very good idea to make a (curated?) list of haxe extensions! But am not sure it’s the best option to try to put everything in the same GitHub team (of course it’s fine if some people want to, but for instance, I don’t want to, even if I am happy to contribute extensions).

I believe a simple repo like Awesome Snowkit listing every extensions (and some other resources) would be much straighforward to do, wouldn’t create any concern about ownership (everybody is free to keep his repo where he want’s etc…) and in general would be as useful.

Oh, it seems that there is already an Awesome Haxe repo by @nadako :smiley: (but it didn’t get updated for 2 years :frowning: ; I guess it would need an “active and regular curator” to make it useful)

Regarding Haxe extensions themselves, I am currently working on iOS/Android extensions for our own Haxe game engine (not openfl-based) but still trying to see how to make them compatible with OpenFL as well. My recent work on an Automatic iOS/Android bindings generator is some part of this effort.

About standards and how to build an extension, I found the linc initiative to work very well for us on Haxe/C++ target. It makes it easy to make and use native extensions without worrying about having precompiled binaries etc… It just build with the rest of the codebase and plays well with compilation cache. This obviously only solve the C++ part (that is why I am working on a binding utility for iOS/Android as a complement of this), but I think it’s a good step forward.

I should have some extensions ready in the coming weeks/months and will be happy to share these to the community when they are ready, but not by moving them to another Github team, sorry. Let me know if you think there can be any other way to contibute extensions though! (Of course haxelib itself is still a valid way to contribute anyway)!


(Flashultra) #7

Native extensions are mandatory and very important part of mobile development ( payments, social login, analytics, etc.) , so I think separate page on haxe site ( similar to https://lib.haxe.org/ ) at example https://extensions.haxe.org/ will give freedom for developers and easy way for users to find the right one. Sure, separate tag in haxe lib also can help , but native extensions are mandatory for mobile ( at least for 90% of all apps)
Congrats Jérémy Faivre ! Really like the idea and what are you doing with ‘bind’