Guidelines

This page discusses some guidelines about using the HaikuPorts' Trac site.

Merging

A port should eventually be merged with the original software's main source tree. Many open source projects use the GNU  Autotools in order to be portable on a source level. While the concept is great,  Autoconf and  Automake are quite daunting. It is however worthwhile to learn at least a minimum about the GNU Autotools. The PortingTips contain links to more information about Autoconf and Automake.

The PortLog

When porting an application or library, it is strongly advised you keep a log of:

• what options are necessary for building on Haiku; and
• what problems you run into, and the solutions to them.

This information can be very helpful to others, after all.

When you get stuck and give up (hey, don't feel bad), create a new ticket explaining the problem. Also link to this ticket from within the port's PortLog. Consult TracLinks on how to do that. The tickets should be assigned to the component that corresponds to the port.

Platforms

HaikuPorts originally started out as BePorts and was going to cover ports for BeOS, Zeta and Haiku. That never really happened and we has since switched to just a single platform, Haiku. There are different ways in which Haiku can be built, the standard release versions are gcc2/gcc4 hybrids, there's also ways to make it gcc2 only, gcc4 only and gcc4/gcc2 hybrid. Bep files are usually tested to work in the gcc2 and gcc4 only builds, if they are found to only work for gcc4 they should be marked as such using a MESSAGE entry: MESSAGE="This port only builds with gcc4."

The status of a port is described by the following keywords:

• untested: not tested on this platform
• broken: doesn't build
• unstable: builds, but fails tests or has obvious flaws
• stable: passes tests and seems to be working as it should

Layout

The layout of the portlogs is controlled by the portlog plug-in. To create a new portlog page, locate its  Gentoo Portage category, then head over to the AddPort? page to create an entry for the port in the database. Once the entry is created you'll be able to create a version, once the version is created you'll need to create a revision 1, which is where you'll write down your build notes.

If the portlog already exists check for prior builds, there might be notes already there which could point out things you might have missed. Don't remove old versions or revisions from the portlog, the information can still be valuable.