= Porting Tips = == Documentation == Some documentation: * A short but very helpful [http://revolf.free.fr/beos/BeGeistert-13/Porting%20Apps%20to%20BeOS.pdf slideset] on porting applications to BeOS by François Revol (mmu_man). * A comprehensive [http://www-src.lip6.fr/homepages/Alexandre.Duret-Lutz/autotools.html tutorial] on the GNU Autotools * Autotools - A Guide to autoconf, automake and libtool [http://www.freesoftwaremagazine.com/books/autotools_a_guide_to_autoconf_automake_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, [wiki:dev-lang/perl 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 [http://www.haiku-os.org/news/2009-01-31/haiku_finally_gets_a_native_gcc4_full_story_inside native GCC4]. === gcc 2.x and 4.x hybrid === The following [http://dev.haiku-os.org/changeset/25536 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 [wiki:dev-util/cvs CVS], [wiki:dev-util/subversion Subversion], [wiki:dev-util/git Git], [wiki:dev-util/mercurial Mercurial] and [wiki:dev-util/bzr 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. 1. 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:[[BR]] {{{ make install DESTDIR=/boot/foo cd /boot/foo/boot zip -ry9 packagename-x.x.x-gccX-haiku-YYYY-MM-DD.zip * }}} Where x.x.x is the rev of the package, and gccX is gcc2 or gcc4, haiku could also be beos or bone or zeta, YYYY is the 4 digit year, MM is the 2 digit month, DD is the 2 digit day (both zero padded).