Picking up the discussion with @nfeske on the mailing-list, about taking advantage of Be apps on SculptOS : this might be done with new repos/ports/*.port files or (more likely!) with Goa projects.

If there's ever a wish to try this out, I've just pushed a few commits with simple apps:

• DeskCalc scientific calculator
• Sudoku game
• the previous demo "classics" are still there too, including Mandelbrot

By working on such 'easy' ports we would detect early issues and porting challenges in a relatively simple environment, before tackling more complex ports.

In the abstract, I guess Goa should perform these tasks:

• download/expand the tarball or zip at https://chiselapp.com/user/ttcoder/repository/genode-haiku/zip/_an_hex_hash_might_be_used_here_ (EDIT: let's use the latest commit : 25e4905634
• configure the build system's environment vars (e.g. $GenodeRepos, possibly the toolchain's rev too) [edit]
• call jam haiku.lib.so
• call jam DeskCalc
• create a package for the lib
• create a package for the app
• test: deploy the library, deploy the app, does the calculator show up in a Motif window as it should ?

In practice, there will be things to work out, to make haiku.lib.so work with standard SculptOS, like configuring it to not use xattr:

• GE_XATTR_DISABLED=1 (otherwise linking will fail with "no such Genode function: path_for_genode_fd()")
• GE_DECORATIONS_AND_WM=1 (otherwise haiku.lib.so creates client-side decorations etc which would conflict with Genode's wm and decorator)

So that would mean building the lib and buliding the app by invoking these:
GE_XATTR_DISABLED=1 GE_DECORATIONS_AND_WM=1 jam -q -j2 haiku.lib.so
and
GE_XATTR_DISABLED=1 GE_DECORATIONS_AND_WM=1 jam -q -j2 DeskCalc

And in order to invoke that, one would need to build the "reference" Jam (rather than use ft-jam or lib-boost jam, which are not quite compatible). (we don't want to go again through troublesome debugging that occured when I suggested Norman use non-compatible Jam variants on Linux, I am still feeling guilty about that!)

Other possible issues:

• my jamfiles are a bit messy currently, in that they don't (all) build to genode/build_dir, some build inside the fossil tree (!) Should probably fix that.
• they also hardcode building for x86_64, but the whole Be code is probably not completely in shape for compiling on Arm etc anyway, so it may be too soon to make the jamfiles architecture-agnostic yet.

If you ever tackle this, hit me with any question you have, I'll do my best to answer, and tweak my jamfiles as needed.