Built Redis on Haiku, porter questions

Hello all.

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?..

Any direction on that would be appreciated.

3 Likes

Read the Haikuports wiki.

I’m all for RTFM but let’s be more informative :slight_smile:
More specifically read this: https://github.com/haikuports/haikuports/wiki/A-Gentle-Introduction-to-HaikuPorter-%231 (and part 2)

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.

Good luck & have fun :slight_smile:

5 Likes

@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.

1 Like

There are more pages in the wiki besides the Gentlies: https://github.com/haikuports/haikuports/wiki/Patching-with-HaikuPorter

KapiX boiled it down to the gist of it… :slight_smile:

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:

server

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?

Relevant part of the recipe:

SOURCE_URI=“git://github.com/antirez/redis.git#6c8a8f2eb7b27b992554b86cd9a93fa6c31b2fcc”
SOURCE_DIR=""
PATCHES=“redis-5.0.patchset”

ARCHITECTURES="!x86_gcc2 x86 !x86_64"
SECONDARY_ARCHITECTURES=“x86”

PROVIDES="
redis_x86
cmd:redis_benchmark_x86
cmd:redis_check_aof_x86
cmd:redis_check_rdb_x86
cmd:redis_cli_x86
cmd:redis_sentinel_x86
cmd:redis_server_x86
"
REQUIRES="
haiku_x86
"

BUILD_REQUIRES="
haiku_x86_devel
cmd:aclocal
cmd:autoconf
cmd:awk
cmd:gcc_x86
cmd:make
"

Just to make sure that I’m not doing it wrong for the first attempt at porting.

1 Like

read about $secondaryArchSuffix and $commandSuffix.

Thanks for the tip on the variables.

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… :thinking:
I’ll keep testing things and trying to boot this in a native Haiku

Analyze other recipes to get more ideas.
You are on the right track btw, congrats, you did the impossible.

1 Like

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).

Thank for the support :wink:

But it is ok with gcc7, no problem.
Porting stuff is great.

gcc2 is provided only for compatibility with BeOS. When porting software from other platforms you should ignore its existence.

1 Like

I hope to get 32bit Support on 64bit in the future :slight_smile:

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, …

@Pahefu As a big proponent of NoSQL, I take my hat off to you for doing this. Nice one!

Does HaikuOS need a high speed in memory cache/database for any of its apps? … Might be an interesting cross-app addition…