After being one of those users of BeOS from the old times when it came on some magazine cds, i thought i could gave a go on porting / compiling some apps for Haiku.
I downloaded the almost-rc 32bit image from @waddlesplash and the latest source for redis on git.
After tweaking the makefiles and some C code for lua dependencies, i compiled Redis succesfully and connected with its own cli tool.
Now i am a bit lost on how to create a package for it to be distributed for haiku users (if some wants to use redis or so), because I had to change both makefiles and c files.
Should i fork redis and create a haikuport recipe with my own github repository? Try to get some fixes as a pull request to redis real maintainer and then create the recipe?..
Since that doesnāt mention anything about patches hereās a basic process:
when you have your recipe with proper download location filled in, you run haikuporter -b redis to unpack the sources but stop after that. Then you go to work-<version>/sources directory and apply your diff there. Itās a git repo, so you should commit that diff and do haikuporter -e redis to export your patchset. You should be able to figure out the rest from the docs.
@extrowerk Thanks, not unexpected fast reply with RTM.
@KapiX I already read the Gentle introduction part 1 before posting here (iām a fan of RTFM before asking) but i was in fact asking about what you replied, patches behavior. Iāll give it a go on the haiku os i used to compile redis and see if i can make it work. Thank you so much.
Of course, if possible itād be best if you cet get your changes upstreamed some time. So we donāt need to apply the patch anymore, and more important, the project upstream will be able to maintain the needed changes.
Gave it a good research session, grabbing branch 5.0 of redis git instead of unstable (doh!) and only had to tune makefiles and make params to compile outside haikuporter.
OK, so i digged all the haikuports topics, had problems on any step where I could have them (expected) and finished with a recipe that builds,is installable and works after installing:
As it has to be built with a modern gcc, i made everything work using the x86 tag, and asking redis to target 32 bits for now.
By doing so, i ended having a hpkg (redis_x86-5.0-1-x86_gcc2.hpkg) and binaries ending with ā-x86ā for all the redis binaries.
Thereās a way to make it ācleanerā without adding that suffix (i.e, having binaries with it), or should it be this way to make it clear about architecture?
With that and other answers from you, I have edited the recipe with em to provide a variable output, and installed both succesfully on my x86_gcc2 Haiku VM. I think it looks kinda hacky for now (as you always need gcc-x86 to build), but iāll take it as my hello world example.
I guess the naming is not quite right as this redis 5.0 branch still shows ā4.9ā on the outputā¦
Iāll keep testing things and trying to boot this in a native Haiku
I already took inspiration on the w3m, recipe on github, and used it here.
I think it wont work with other than including that lib, because of the redis code itself (has params and other flags that are beyond gcc2 available ones), so itāll not be gcc2 compatible ever. Probably a ādead endā there.
Having done this, iāll try to experiment more and try port other libraries that i have experience with, eventually uploading them to the official repo (whenever possible).
Redis has makefile params for 64 bits. I just took the 32flags to make it work on the current machine, so the receipe would only need to be modified removing ā32bitā flag on it (or use some conditional for this).
Without any further changes, one person can now use redis as a cache backend for things like php or some apps that use cache like Celery tasker, NodeJS apps, Django framework, ā¦
