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 autoconf, 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, or you can:

 cp /boot/common/share/libtool/config/config.* .

Where . is the package root folder, or the folder in which the package has outdated config.guess and/or config.sub files. If trying to build static and shared libraries, you may also need to run (try using ./autogen.sh first if it exists, it usually runs all the autotools as needed):

 libtoolize --force --copy
 aclocal
 automake
 autoconf

Which "should" force the Haiku cases into your configure file. You might have to use other options to get aclocal/automake/autoconf to do this successfully.

gcc 4.x

Haiku now has a  native GCC4.

gcc 2.x and 4.x hybrid

The following  ticket explains how to build a Haiku image that runs both gcc 2.x and 4.x executables.

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.

Preparing an archive for distribution

There are two methods for creating an archive for distribution, using DESTDIR and using diff_zip.

For both situations, please use the following nomeclature as the <archivename> :
<packagename>-<version>-<gcc-version>-<os>-<date>.zip

  <packagename> = is the name of the software.
  <version> =  the revision number of the actual software.
  <gcc-version> = [ gcc2 | gcc4 ]
  <os> = [ haiku | zeta | bone ]
  <date> YYYY-MM-DD format and can be extracted by running `date +%Y-%m-%d`

DESTDIR is the preferred method :

 mkdir /boot/foo
 make install DESTDIR=/boot/foo
 cd /boot/foo/boot
 zip -r9y <archivename>.zip *

diff_zip is an alternate method :
Some software packages do not support the use of DESTDIR. For these cases, diff_zip is your friend. It was added to Haiku's source tree in  revision 24849. Once the newly compiled software is ready to install, diff_zip is run in a second Terminal session. diff_zip will patiently wait for you to install the software. After installation, return to the second Terminal session to inform diff_zip to archive the newly added files.

  [terminal 1] make
  [terminal 2] cd ~/upload
  [terminal 2] diff_zip -r9y <archivename> -- <paths>
  [terminal 1] make install
  [terminal 2] #press enter to activate diff_zip

Using CMake

If you find a CMakeLists.txt file in a package you are porting chances are it's using CMake. If you don't already have CMake installed go ahead and grab the  binary and install it. Then try running cmake CMakeLists.txt or for the interactive ncurses version try ccmake CMakeLists.txt. Once the configuring is done, you use the normal make, make install, type commands, note the output may look different than you are used to. One thing you might notice with CMake is that configuring, fixing and configuring may go faster since it keeps track of where in the configure process it left of at. Feel free to update these notes as we will be seeing CMake more and more.  CMake documentation

Directories

As of Haiku R29880 several directories have been relocated. For details see the Haiku Developer's mailing list archive:  http://www.freelists.org/post/haiku-development/Directory-renaming Feel free to update this entry with more details on possible fixes and details on how and where to use find_directory()