I’ve finally got Wonderbrush 3 to compile on x86 using setarch x86 and jam -q -j4. For as long as it took me to figure out that it doesn’t work with either x86_64 or GCC2, it seems I need a crash course in modifying Jamfiles.
Stippi’s work on the Wonderbrush rewrite coupled with my attempt to make a glyph editor needs removal of unnecessary functions in order to make it simpler and vector-only in my “Glyph-O-Matic” fork but I’m beginning to wonder if it wouldn’t be better just to finish WonderBrush 3 and save the subset for later.
My philosophy about native Haiku executable programs suffering from the “not invented here” syndrome and rejecting “foreign” codes as being unnecessary and damaging to the Haiku community may give way to another philosophy: Don’t knock it until you’ve tried it. I’ve never worked on a Haiku-native program before and I might never again the way things are going. On the plus side, however, if I do get familiar with Haiku native APIs, I could rig up a Haiku native code generator for WebAssembly byte-code or something to lower the barrier of entry for external ports to use native GUI functionality and the like.
Good news! Jam is well-documented! Except we don’t seem to have the HTML files online anywhere except as source files. Anyway, you can find the documents in /boot/system/documentation/packages/jam/. Jam.html is a good starting point.
Good luck
Lol, I suppose it’s true that we suffer from NIH syndrome! The whole project is a reinvention of the wheel! To an extent, that’s the fun of it. At least, until you get to the nitty-gritty implementation details…
But yes, Haiku’s API does have some nice concepts in it.
WebAssembly Micro Runtime is designed to make a common runtime for cross-architecture development. If it could be expanded to embrace the Haiku APIs, we could make cross-architecture developments more commonplace. Also, the bytecode generated packages could be shared with the Haiku-on-Genode project without much fuss.
I’ve attempted things like this before but what I keep running into is that the final code generation phase takes a long time. When I ported W2C2, it worked but the C code it generated took almost as long to compile as the sources that were compiled to WebAssembly in the first place.
By the way, thanks for pointing out the Jam documentation. I’ll see what I can do.
Ah, so part of making it work would involve making Haiku API bindings for WASM? I’ve worked on API bindings for Python. There’s a good chance you’ll encounter some tricky corner cases, but hopefully most of it is relatively easy.
TBH, I’m not very familiar with Genode or the other uses of having WebAssembly, but I suppose it could be interesting, especially if it gets to the point where you can replace Haiku’s kernel with Genode.
Anyway, good luck out there with WonderBrush 3. I’ve looked at it before and thought, “hmm, this could get interesting. Too bad it’s abandoned.” One thing I noticed was Icon-O-Matic and WonderBrush have similar code bases, so WonderBrush has a special place in my heart. Glad to see WonderBrush 3 is getting some attention
Contradictory, Ham was created precisely because of limitations and bugs in Jam years ago, it was continued in gsoc in 2022, it makes no sense to say that Jam meets Haiku’s needs.
It’s just inactive, but stippi will review patches if someone submits some.
It does. Ham is a feature-for-feature rewrite, or at least was started this way. There are a few things that could be improved in jam, but really, building an entire operating system is inherently complex, and no build tool would really solve that entirely. And jam is quite flexible and suitable, even if it’s a bit quirky.
Most of toe difficulties come, I think, not from jam itself (it’s a pretty simple tool all things considered), but from the build rules and customizations we put on top of it over the years, which are not that well documented.
