How to Set Up a Haiku Development Environment and Build From Source

Writing native software for Haiku means working with the Kit-based C++ API directly. This walks through setting up the toolchain, building a minimal application, and — for anyone who wants to go further — building Haiku itself from source.

Step 1: install the native development tools

pkgman install haiku_devel gcc make

Haiku ships its native development tools as ordinary packages, installed the same way as any other software — see installing and managing software with HaikuDepot and pkgman if this is unfamiliar.

Step 2: write a minimal application using the Application and Interface Kits

#include <Application.h>
#include <Window.h>

class MyWindow : public BWindow {
public:
    MyWindow() : BWindow(BRect(100, 100, 400, 300), "Hello Haiku",
                          B_TITLED_WINDOW, B_QUIT_ON_WINDOW_CLOSE) {}
};

int main() {
    BApplication app("application/x-vnd.example-HelloHaiku");
    MyWindow* window = new MyWindow();
    window->Show();
    app.Run();
    return 0;
}

Every Haiku GUI application follows this same basic shape: a BApplication subclass (or instance) as the entry point, and one or more BWindows — themselves BLoopers, per the Looper/Handler pattern — doing the actual work.

Step 3: compile it

g++ hello.cpp -o hello -lbe

-lbe links against libbe, the shared library containing the Application, Interface, Storage, and other core Kits — the single native library most Haiku applications link against for the bulk of their functionality.

Step 4: run and confirm it behaves as a normal Haiku app

./hello

A correctly built application should appear as an ordinary window, respond to standard window controls, and quit cleanly — confirming the toolchain and linking are both working correctly before building anything more complex.

Step 5: use a resource file for an application icon and metadata

# a .rdef file describes app metadata/resources in a
# human-readable format, compiled with rc:
rc -o hello.rsrc hello.rdef
xres -o hello hello.rsrc

Haiku applications carry their icon and metadata as BFS attributes and embedded resources rather than a separate external file — this step attaches that data to the compiled binary directly.

Step 6: clone and set up the Haiku source tree, if building the OS itself

git clone https://review.haiku-os.org/haiku
git clone https://review.haiku-os.org/buildtools

Building Haiku itself (rather than just an application for it) is a substantially larger undertaking, requiring the buildtools cross-compilation toolchain alongside the main haiku source tree.

Step 7: configure and build using jam

cd haiku
./configure --cross-tools-source ../buildtools --build-cross-tools x86_64
jam -q @nightly-anyboot

Haiku’s build system uses Jam rather than more commonly seen tools like Make or CMake — a deliberate, long-standing choice inherited from BeOS-era tooling, distinct enough from mainstream build systems to be worth knowing about upfront rather than assuming standard Make conventions apply.

Step 8: test a custom-built image in a VM before anything else

Boot the resulting image (nightly-anyboot, or wherever jam places its output) in a virtual machine first, the same way installing Haiku generally recommends — especially important for a self-built image, since confirming it boots correctly in a controlled environment is much faster to iterate on than testing directly on physical hardware.

Why linking against libbe is the one thing almost every Haiku app needs

Nearly every native Haiku application, regardless of what it actually does, needs the Application Kit at minimum to exist as a runnable program at all — which is why -lbe shows up in essentially every native build command, and why understanding the Kit-based API’s structure (covered in more depth in Haiku’s kit-based API) is the actual prerequisite for native Haiku development, more so than any specific build-system detail.