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.
Places to check
Places to check for previous ports (though not all BeOS hacks are needed for Haiku):
- http://revolf.free.fr/beos/patches/
- http://geekgadgets.back2roots.org/ has many old ports of stuff to BeOS.
- Searching for 'beos' on opensource project hosting sites like :
- bug/patch management of the target project might contain old unapplied patches.
- developer mailing lists archives
- most are mirrored on http://gmane.org/find.php
Getting started on Haiku
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
cp /boot/common/data/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 or ./bootstrap.sh first if it exists, it usually runs all the autotools as needed):
libtoolize --force --copy --install aclocal automake autoconf
or
libtoolize --force --copy --install autoreconf -i
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 article explains how to build a Haiku image that runs and is able to build both gcc 2.x and 4.x executables.
Porting considerations
To automatically patch software with the HaikuPorter 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:
- Download and try the latest released source tarball. If it works, no further steps are necessary.
- 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 HaikuPorter 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 for distribution
HaikuPorter has a command line option -d which will build the package and then zip it up. Be sure to check that this works correctly if you are creating .bep files. It's usually good to check the builds with -c -d to first clean out the build directory. To see a full list of Haikuporter's command line options use haikuporter -h
Providing Distributions
If the package does not have any of the C++ runtime symbols, then a single package can be created. However if the package is gcc/ABI sensitive, then it should be released as two archives. Ideally one compiled with gcc2 and the other compiled with gcc4. For packages that are only compiled with one gcc, eg gcc4-only software, then a second archive should be created for use with gcc2hybrids.
- packaging a gcc4-only item for a gcc2 hybrid
- libraries go into */lib/gcc4
- add-ons go into */add-ons/<folder>/gcc4 -- eg, add-ons/Translators/gcc4
- packaging a gcc2-only item for a gcc4 hybrid
- libraries go into */lib/gcc2
- add-ons go into */add-ons/<folder>/gcc2 -- eg, add-ons/Translators/gcc2
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 use 'installoptionalpackage cmake' to install it. Then try running 'cmake .' or for the interactive ncurses version try 'ccmake .' 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 off 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 For more details on how and where to use find_directory() and finddir see FindDirectory.
