I’m just starting to learn how to bring some favorite linux projects over to Haiku 32-bit.
I have a simple SDL2 project, and after first searching around and learning about “setarch x86” and installing libsdl2_x86_devel from HaikuDepot I was able to simply make and run from the the terminal windows, so that’s really great.
After a few hours of searching and reading last night it seems that this isn’t considered a best practice though, and that I really should be going through HaikuPorts, etc…
Is that a correct assumption, that I really should be creating and installing a package and not just make-ing and sticking my binary somewhere on my path?
Moreover, since this project builds cleanly on x86, it’s probably a good candidate for my first dive into HaikuPorts?
It depends if that’s something you do for yourself or something that you want to share.
In the case of a private thing, you can compile the way you did and make the package from binaries using HPKGCreator.
If that’s something that you want to share, setting up Haikuporter and making a recipe is the best way. But, you can also choose another repo than Haikuports or even create your own.
Actually, this reminds me of an etiquette question I have. Is it cool to share a recipe for someone else’s GitHub repo, or should I fork it and make the recipe on my fork?
At least at haikuports we urge to use upstream as much as possible and not go about cloning the original source to personal repositories. Forking is another thing, it enables you (in case it’s needed) to create upstream PR (pull-requests).
If you use my HPKGCreator you can create stand alone packages for you own repository or website (download). You can ask other repository owner to share your package too.
Depends on the license of this third party github repo, but if it’s available to public, by definition you’re free to make a haikuports recipe for it, what could be an issue is about the distribution of this port if the licence doesn’t allow it without explicit grant. Would be a weird case, but authors copyright is authors copyright.
So check first the licence, if any, of the source of this someone else’s github repo.
Notice that if you need to make some small changes in order to port it via haikuporter, you don’t need to fork, you can just manage patches files co-located to the recipe.
But if you want to, later, upstream your changes to the original repo, to add specific haiku-os platform support or/and to fix or improve some code for everyone, having a fork will ease a lot to make Pull Request to this someone else repo.
Nothing wrong with HPKGCreator. But it’s like an IDE.
What do I mean by that? If you know how to write code in a text editor and compile it from the command line, you can safely use an IDE, because you know what is happening behind the scenes and you can step in if something goes wrong.
The same thing applies here. HPKGCreator is a front-end for the package command. So read up on that first, create a few simple packages on the command line, just to see if you can make something that installs, runs and uninstalls, and then you can move on to HPKGCreator for the convenience it offers.