Porting Tips

Documentation

Some documentation:

• A short but very helpful  slideset on porting applications to BeOS by François Revol (mmu_man).
• A comprehensive  tutorial on the GNU Autotools
• Autotools - A Guide to Autocong automake and Libtool  ebook

The CommonProblems page lists a number of common problems encountered when porting applications to BeOS.

Getting started on Haiku OS

gcc 2.x (default)

When building your own Haiku image, you can add

AddOptionalHaikuImagePackages Development ;

to your build/jam/UserBuildConfig file. This sets up a development environment and unzips a small tree of ready-to-use binary tools onto your image, including a Haiku-specific gcc2, Perl and autotools. Other helpful packages are OpenSSL and the Pe text editor (which allows you to jump to the line of an error message) and Firefox (which allows you to copy-and-paste console output to our Wiki pages).

Most software cannot handle i586-pc-haiku yet, so it is usually necessary to configure with --build=i586-pc-beos.

gcc 4.x

A native development environment is not yet available for gcc4-based Haiku; the cross-compiler can be used instead.

A  shell script to aid in this is available for use with autotools based software.

Porting considerations

To automatically patch software with the BePorter? tool, source tarballs should be diff'ed (cf. CreatePatch).

Most projects however use SCM/VCS software, including CVS, Subversion, Git, Mercurial and Bazaar, and accept patches only against their latest (HEAD/trunk/master) development version. A possible strategy is:

1. Download and try the latest released source tarball. If it works, no further steps are necessary.
2. Otherwise, check if the project maintains a publicly accessible (anonymous) source code repository. You might be able to choose between a branch corresponding to the version number of the source tarball, or trunk/master. (Terminology varies between the VCS tools.)

Doing so, you can easily track or revert your own changes, and this is the preferred format for submitting patches to the respective projects.

Note that it is not easily automatable for BePorter? though, but once accepted, future source tarballs promise to compile without patching.

Also note that doing so may, depending on the project, result in more dependencies but might be easier to handle, for instance when modifying configure.in or Makefile.am instead of an Autoconf-generated configure or Automake-generated Makefile.

Building to a clean folder and making a binary

Many packages have an option to do a "make install", in many of those cases you can use:

• make install DESTDIR=/boot/foo
• cd /boot/foo/boot
• zip -ry9 foo-x.x.x-haiku-#.zip *

Where x.x.x is the rev of the package, and # is the portlog revision, which will usually be 1.