What is the proper way to build target-specific libraries using HXML?

Hi all,

I’ve written a dense matrix + vector library that is primarily meant to be used within larger Haxe programs and libraries, but I do also intend to use it as an importable module in Lua for REPL interactivity (as well as eventually in Node, JVM languages, and C++).

I can build it as an importable library for Lua already using the Haxe command like so:

haxe --lua dense_linear_algebra.lua --class-path src dense/Vector.hx dense/Matrix.hx

And then after entering a Lua REPL, can utilize it like so:

dla = require 'dense_linear_algebra'
Vector, Matrix = dla.dense.Vector, dla.dense.Matrix

vec = Vector.generate(7, function(i) return i * 5.0 + 1 end)
vec:get(4)
vec:dotProduct(vec)
vec:normalize()

It builds fine in that manner, and I’m already successfully using it that way. I guess where I’m stuck is that in HXML, I don’t know how to include stray files like that without there being a “–main” option. I’ve tried using a “–macro include(‘dense/Vector.hx’)” but the file output is quite different in both content and behavior (and I’m not even sure that is the proper option to use in the first place).

I can of course write shell scripts but those aren’t as portable (for those using Windows) and I’d like to stay in the Haxe ecosystem nonetheless while still automating the process.

What is the proper way to accomplish this? Also, where is the best place to understand the nuances and options associated with HXML? I can of course see the intro in the guide, but I know I’ve seen more options elaborated on somewhere else before and just cannot locate it again. Of course diving into the codebase is always an option. I’ll be writing a series of libraries in this manner so this solution is something that I will get a lot of mileage out of.

Thanks for any guidance here!

2 Likes

I’m sure one of the real Haxe experts will blow my comments out of the water, but perhaps this will help a bit. I don’t fully understand what you are building but thought I should mention about compiling multiple targets in a single hxml file. You would separate them with a --next directive, and they can use the same code but different targets. Here’s an example I have from an old project, targeting PHP and Neko:

-lib ufront-mvc
-lib hx3compat
-lib ufront-mail
-lib express
-lib tink_core
-D server
-cp src
-main Server
--php-front index.php
-php www/

# remove cache file to prevent cache errors after adding classes
-cmd (rm -f ./www/cache/haxe_autoload.php )  
-dce no

--macro allowPackage('controller')
--macro include('controller.AboutController')


--next

-lib ufront-mvc
-lib express
-lib tink_core
-D server
-cp src
-main Server
-neko www/index.n 
# nekotools server -p 2000 -h localhost -d /Users/me/Documents/site/ufront/www

It also sounds like you might find embedded resources to be a useful compile-time feature.
In this case, since the Server.hx file compiles to both targets, you would use conditional compilation flags in that for target-specific behaviour. e.g. #if php trace("Hello from PHP”); #end
I hope that helps a little!

1 Like

It doesn’t seem to be in the documentation, but you can add the path to your files in the hxml directly:

--lua dense_linear_algebra.lua
--class-path src
dense.Vector
dense.Matrix

That should do what you need.

Other than this and the run arguments (explained in a comment in the link above) a hxml file simply takes the normal cli arguments, one per line.

1 Like

Hi and welcome! :slight_smile: Maybe you can find some more infos in this thread :

1 Like

Thank you all - with your help, I was able to release my first library on Haxelib today!

Valentin - that did the trick! I don’t know why I didn’t just try that in the first place, but I was making an erroneous assumption that everything in an HXML file had to be prepended by a flag of some sort.

Allan - your advice helped me build a separate unit testing HXML script that compiled my library to each target and ran the tests there, and a separate script that compiled my library to importable modules for each of the scripting targets, so that information was super useful. That link on embedded resources was very much appreciated, given that what I’m planning on doing over the next two years will benefit greatly from embedding assets.

tokiop - I appreciate that thread and being able to see some of the obstacles others have encountered in writing native libraries for other languages using Haxe. Outside of using them as subcomponents in standalone Haxe applications (via whatever target), I will mostly be using them in the context of Lua / Fennel, and maybe JS or Python. The library worked fantastically in all three of those targets so far and I didn’t bump into any obstacles, but I’m guessing I should try them out in some of the non-scripting targets to see if it is as frictionless. That thread gives me the notion that I may need to see how well a program written in a target first and foremost works with multiple libraries that I write in Haxe and import as libraries.

As for what my libraries aim to achieve - I wrote early versions of them in Fennel last year but increasingly realized that proceeding without typing was going to be a bad design choice that I would pay for many times. Thought of Teal but Haxe won me over with how many environments it can be in (though Lua is quite portable itself as a C library, though building things with it can get extremely bespoke).

The idea is that my dense linear algebra library will support the port of my neural networks library, which is to be used by a port of my genetic algorithms library. I intend to release a series of tiny games and apps over the next year, where I cultivate game-playing neural networks, then embed my neural networks into these apps, so that I can challenge friends, family members, and app-store users to see if they are “smarter than arrays of floating-point numbers”. Also, having such libraries would allow me to avoid having to code game-playing AI logic by hand, for any game whose state can be one-hot encoded, and have low footprint, simple, drop-in logic that I don’t need to understand but still produces believable “players” (moreso for some games than others). I’m also planning on using these libraries to study the cultivation of hyperparameters (genetic algorithms that “breed” / train genetic algorithms themselves). Rolling this by hand is a bucket list item for me.

Allan - your RTA Outdoor Kitchen application, along with watabou’s City Viewer, persuaded me two weeks ago to give OpenFL a look, and after examination of so many other engines / frameworks, is what I’ve decided to proceed with. I’ve also been persuaded to use Away3d over OpenFL for a game (well, an experience) I’ve been planning for a while. I appreciate the inspiration!

3 Likes

Sorry, I just saw this…glad I was able to help out! I look forward to seeing your game!

1 Like