Concerns Regarding the Development of Haiku OS Cross-Platform Applications

1

Hello Everyone,

Haiku has recently piqued my interest because to its distinctive approach to being efficient, lightweight, and loyal to the BeOS heritage. As a developer who has worked on cross-platform apps, I’m interested in how Haiku manages the development process in contrast to more popular operating systems like Windows, Linux, or macOS.

In particular, I would like the community to assist me in answering the following questions:

Toolchains and IDEs: Which toolchains and IDEs are most suited for creating native Haiku applications? I’ve read about the Paladin IDE, but are there any other popular contemporary options? :thinking:

Cross-Platform Compatibility: How difficult is it to convert current Windows or Linux apps to Haiku? :thinking: Are there any tools or libraries that facilitate this process? Although Haiku complies with POSIX, I’d still like to hear about actual experiences.

Application Distribution: How is distribution usually managed after an application is created for Haiku? Are there central app stores or repositories? Which method do users most frequently utilise to download and install apps? :thinking:

Local Resources: Would you suggest any particular books or guides to someone wishing to learn Haiku development? :thinking: Although I’ve already perused official literature, I’m searching for more comprehensive manuals or community-driven materials.

https://discuss.haiku-os.org/t/what-is-the-development-workflow-for-non-haiku-oses/

I can’t wait to participate and gain more knowledge about this incredible operating system. Any advice, experiences, or insights would be much valued.

Thanks in advance for your help and support.

1 Like
2

Paladin is old and probably needs some developer attention. Install Genio instead. Or if you want more of a RAD experience, try yab.

Windows apps? Can’t think of any. A large percentage of user-facing apps in the depot are actually ported QT/KDE applications. GTK is less developed in the Haiku world, but it’s there. Wouldn’t have GIMP without it. We have Java, too, and since recently, FLTK. We have Python3, Perl and Ruby,though those tend to work best for CLI applications.

EDIT: Nearly forgot: We have FreePascal.

Haikudepot. It’s an app in the Deskbar menu and there is a CLI interface as well. If you want more you can add the FatElk and Besly repositories.

3

My preferred IDE on Haiku is Genio,which is a native Haiku application.It has many features like Git integration and checks for errors using Clang,but it’s still very fast and rather lightweight,compared to non-native alternatives.
Alternatively,ported IDEs from other platforms are available.KDevelop from KDE is a very powerful example,but if I know right,there are some others as well.

How difficult it is to port an existing apps depends on the libraries needed for it.If it’s a cross-platform application,there’s a good change it uses Qt or GTK for the UI stuff.Both are available,while Qt integrates really great and looks nearly native,and GTK clearly shows you it comes from another OS with another design,but technically it works.
If those are used,you can probably just try to compile your code on Haiku and it may work,or need some small modifications.
Windows applications could work in Wine,but besides that,there’s no way of easily porting them to Haiku.Windows has own libraries for UI and such which are closed-source and therefore not available anywhere else.

Applications are usually distributed using HaikuPorts which is the default software repository that all Haiku installs use.Besides that,there’s also the possibility to distribute the .hpkg package files on your own server or ask one of the alternative repositories for inclusion.

The Haiku Book and the Be Book will be useful if you want to create native Haiku applications or try to put some native elements into your cross-platform apps (but I must admit I don’t know how good mixing native with cross-platform code works).
The Haiku Book: Welcome to the Haiku Book - The Haiku Book is the current documentation which gets updated when anything changes,but it’s still missing documentation of some longstanding APIs since they’re in the Be Book already.
The Be Book - The Be Book is the official documentation for BeOS which is mostly still valid for Haiku since it’s API-compatible.New features of Haiku are not included and it will never receive updated since the license doesn’t allow modifications.But the Be Book is very detailed and therefore still useful today.

4

Hello, Daisy,

Michel and Nipos have answered your questions, and you may get more replies, but I would just like to say welcome to the forum and to Haiku.

The project is making steady progress, but it would be great to have more developrs on board.

5

I use QtCreator for Haiku native apps since it has excellent code completion. This requires cmake as your build system. When I say native, I do actually mean BApi kits. The native Debugger lets you step through the code visually, you can also use QtCreator for visual debugging since gdb is also working well.

We look forward to seeing what you’ll create.

6

This is the first time daisynaive96 has posted — let’s welcome them to our community!

I’m getting quite annoyed of this this stuff.

You aren’t clever by posting lots of useless questions and then hiding spam links to training services in your posts.

The (presumeably) ai generated avatar beeing the same style doesn’t help either.

This account is suspended for spamming.

I am happy our community is so helpfull, in this case you got baited a bit. Sorry :slightly_frowning_face:

7

Hi @daisynaive96, and welcome!

Depends what exactly you mean by “apps”. If you mean applications with a GUI interface, @michel already covered your options. But since I guess “cross-platform” is what you are looking for I can tell, from personal experience, migrating a program or library I wrote for GNU/Linux or FreeBSD to Haiku is really very simple, and only slightly different in the Window$ case (provided you don’t use Window$-only stuff, like DirectX or whatever it is called nowadays).
Since you talk about “cross-platform” you obviously need a compiler that will work on any operating system (and libraries available there, of course). My choice is GCC, and this is a generic Makefile I use for that purpose. It works on all operating systems I mentioned above:

# Generic makefile
#-------------------------------------------------------------------------------
TEST_STRING = $(shell echo "test")
ifeq ($(TEST_STRING),test)
	TARGET_OS = Unix
	ifeq ($(shell uname), Linux)
		MAKE = make -j
		USR_DIR = /usr
		ifeq ($(shell getconf LONG_BIT), 64)
			SYSTEM_LIB_DIR=$(USR_DIR)/lib64
		else
			SYSTEM_LIB_DIR=$(USR_DIR)/lib
		endif
	else ifeq ($(shell uname), FreeBSD)
		MAKE = gmake -j
		USR_DIR = /usr/local
		SYSTEM_LIB_DIR=$(USR_DIR)/lib
	else ifeq ($(shell uname), Haiku)
		MAKE=make
		USR_DIR=/boot/home/config/non-packaged
		SYSTEM_LIB_DIR=$(USR_DIR)/lib
	endif
	SYSTEM_INC_DIR = $(USR_DIR)/include
else ifeq ($(TEST_STRING), "test")
	TARGET_OS = Windows
	MAKE = make -j
	USR_DIR = D:\Pap\usr
	SYSTEM_INC_DIR = $(USR_DIR)\include
	ifeq ($(findstring 64, $(shell wmic os get osarchitecture)), 64)
		SYSTEM_LIB_DIR=$(USR_DIR)\lib64
	else
		SYSTEM_LIB_DIR=$(USR_DIR)\lib
	endif
endif

include Makefile.$(TARGET_OS)
#-------------------------------------------------------------------------------

All it does is “detecting” what operating system you are working on and sets the appropriate include and library directories. In the end, it loads the main Makefile. Notice how GNU/Linux, FreeBSD, and Haiku all fall in the Unix category: The generic Makefile just loads Makefile.Unix, which is identical for all three systems. Also note that in the Haiku case, I place includes and libs in the non-packaged directory during developing.
I can post a listing of Makefile.Unix if you wish, but really, there is no need to do so: It’s what you would expect, there is nothing new or Haiku-specific there. Once include and lib directories are set, the rest is one main Makefile for all three systems.
Now, Makefile.Windows is slightly different, mainly because of backslash \ instead of slash /, and personal preferences.

I use that method for 2 years now, and it just works very well. Porting apps from/to any of the “Unix-like” systems is literally seamless, and that includes graphical applications using, e.g., GLFW and OpenGL, or other libraries. Even my editor of choice (Emacs) is available on Haiku, so for me it’s common practice to start a project in, say, FreeBSD and continue developing it on Haiku the next day, then to GNU/Linux and so on, with zero changes.

I generally don’t use GUIs so I can’t talk much about this case, but if I were to guess, I would say the Makefiles won’t be much different if you need Qt or GTK. For native Haiku applications, Genio is the obvious choice nowadays.

8

I just noticed @nephele’s post. Spammer’s failed attack, it seems I didn’t see any hidden spamming, presumably because I use blockers. I guess my answer isn’t needed anymore, but I’ll leave it in case someone else needs it. Feel free to delete it, anyway.

9

I’ve deleted the spam link out of the post.

I’ve kept up the topic this time since this is atleast the second time this happened. So the community is atleast a bit aware of it.

2 Likes
10

“migrating a program or library I wrote for GNU/Linux or FreeBSD to Haiku is really very simple, and only slightly different in the Window$ case. …Porting apps from/to any of the “Unix-like” systems is literally seamless, and that includes graphical applications.”

Interesting post. Since it is relatively easy to port apps, is there an argument for releasing a “developer” edition of Haiku - with all available programming languages, IDEs, compilers, libraries, tools, documentation, etc installed and ready to go? This might encourage those who want to dabble in porting, and eventully contribute to development.

11

What’s the point of shipping all of them?
I doubt any single developer will ever need all of the IDEs or programming languages.
It’s all available for free in the HaikuDepot,only a mouse click away,so you can install exactly what you need and don’t waste space.
Maybe some notes about available IDEs or languages could be added to the developer documentation,if that’s what you want,but I don’t see a benefit in preinstalling them all.

4 Likes
12

That would be useful, but I am guessing a developer who is able to port a library or application would easily find his way with pkgman or HaikuDepot to install the compiler(s) and libraries needed. It is also safe to assume they already have their compiler, IDE, etc of choice and they would normally use just those, not everything available.
Furthermore, Haiku’s Installer brings along not only Haiku itself, but also all the additional packages the user already installed (even settings). I exploit that feature to just create a USB installation that serves as my personal “Haiku developer’s edition”, with all the tools I need already pre-installed and tailor-made for me. I can then use that USB to install on new hardware, whenever needed.

So I guess Haiku developers should spend their valuable free time on something else than a “developer edition”. It’s not that such a thing would be useless, though. I recently discovered a useful library I was not aware of, and that only because I used another person’s computer who had everything installed, all developer’s tools, even the ones he doesn’t use.

The only real issue I encounter with porting is different versions of necessary libraries. For example, I recently ported a library that uses GLFW 3.4.0 but at the moment Haiku has GLFW 3.3.7, where some features are missing. I managed to bypass the issue with a workaround (which will only be useful until Haiku updates that library). Usually this is not a serious problem and doesn’t happen that often, it’s just annoying and requires extra work when it happens. It is also worth noting that this is not a Haiku issue, I have the same “problem” when porting from GNU/Linux to FreeBSD or vice-versa.

13

7 posts were merged into an existing topic: Metapackage support in HaikuDepot

14

I don’t think we have the same usecase as linux does for a multimedia edition etc.

No need to install different drivers or different sound servers or whatever on haiku. It’s simply just some apps. At that point you basically only have “flavors” to install.

Debian does this, the installer asks you what desktop to install, no reason our installer could not be packed with some more optional packages as a “flavor” and install some more applications if asked to.

15

Would that bloat the ISO image? A compressed DVD-ROM image doesn’t have to be 4 GiB, after all.

16

Hmm. Probably not.

We can keep the current installer, maybe make the rest available as “netinstall” and just download it then and there.

1 Like