What is a Haiku Hybrid?
Haiku hybrid images are Haiku releases which can compile and execute programs built for incompatible ABIs. This may mean different architectures like x86-64 and x86, or different, incompatible compilers like gcc2.95 and gcc13.x for x86. Currently only the latter case is supported. gcc2.95 gives Haiku binary compatibility with native legacy applications written for the BeOS.
In a Haiku Hybrid, there is the primary GCC or architecture and the secondary GCC or architecture. The primary GCC is the version that was used to compile Haiku. The secondary GCC provides both a runtime time environment and a cross-compiler for using and creating other-GCC objects.
With the introduction of package management, optional packages - and therefore this page - became obsolete.
This page details the steps in creating an OptionalPackage. In addition to being a regular binary distribution archive, an OptionPackage includes a plain text file called .OptionalPackageDescription and possibly the license file.
As with many other FOSS mailing lists, we at Haiku hold ourselves to a few rules when posting to mailing lists. For now most of these are to ensure that all information is properly archived or to improve a message's readability. In the future this list may be expanded with additional detail.
No Attachments
Not only are attachments inconsiderate to low-bandwidth users, they fail to be preserved in the archives. The latter issue creates gaps of information. Here are some alternatives for sharing your attachment in an acceptable manner, grouped by content type.
Text
Text includes files such as in patches, syslogs, or debugging information. Ideally all patches for Haiku's source code should be attached to a ticket in the bugtracker. If no appropriate ticket exists, then a new "enhancement" ticket should be created. All other text should be posted to a pastebin service, such as http://haiku.pastebin.com. Selecting a lifespan of "forever", will preserve the contents indefinitely. The url for that content can then be included. Another option, which may be better suited for smaller snippets of text is to include it directly in the message body.
In addition to configure options, UserBuildConfig is another, very powerful opportunity for customizing your build. As of changeset [29161], Haiku's build system supports two locations for UserBuildConfig:
- $(HAIKU_TOP)/build/jam/UserBuildConfig
$(HAIKU_TOP) refers to the top level of your local copy of the Git tree. If you use an external object directory, the UserBuildConfig at this location will apply to all of them. - $(HAIKU_OUTPUT_DIR)/UserBuildConfig
Typically, $(HAIKU_OUTPUT_DIR) is $(HAIKU_TOP)/generated. However if you use an external object directory, then it UserBuildConfig is in that top-level directory. The UserBuildConfig in this file applies only to that object directory and over-rides $(HAIKU_TOP)/build/jam/UserBuildConfig.
Old Method vs Build Profiles
Essentially, the 'old method' has UserBuildConfig listing all of the statements globally. This can cause unexpected results when used at the same time of build profiles. Ideally, UserBuildConfig files are created using build profiles and contain statements inside a case statement; this will ensure that the statements of one build profile do not affect the statements of another.
Haiku uses a custom fork of Perforce's Jam. This mailing list thread helps to explain the decision to fork jam.
As of August 2019, this is the current version. If a different version is reported, then you will need to build and install jam from source.
jam -v
Jam 2.5-haiku-20111222. OS=LINUX. Copyright 1993-2002 Christopher Seiwald.
Only some of the options are being discussed here. See
jam -h for a full listing of available options.
Like many other software projects, Haiku allows a user to run configure from a directory outside of the source tree. This will cause the build system to use that current directory as the target location for storing the output from compiling, otherwise known as objects.
There are a few reasons for doing this. Multiple products, such as x86_gcc13, x86_gcc2, or arm can all be built from the same source tree, which reduces disk space usage. The object directory can be placed on a completely different partition or disk for that matter. This helps to minimize data loss in the event of file system corruption. Granted, this shouldn't occur but Haiku is still pre-R1. Another reason, albeit trivial in functionality is that this will keep your source directory clean and free of any generated files. This could be useful for people who keep the sources on a USB stick or SSD and want the compiled objects to be built on a mechanical hard disk or ram drive.
Body:
In reading some of the posts on R1 and R2 (especialy in regards to the quality of user experience) I realized that maybe more conceptual and inovative approach would to OS media design experience would also be attractive for first time users.
For example - just like using vector graphics (especialy in icons) that would make the interface scale and look better, it would be also interesting to use procedural/generative media...for example instead of delivering single quality fixed sound files it would be great to have them generated on the fly with SuperColider
(http://en.wikipedia.org/wiki/SuperCollider).
In this way one would be able to avoid hearing always the same sound when booting the system - but instead hear a tune that is not only variable, but also unique to his system (especialy if it uses system info to render specific sound)...that way it would be similar to the ida of older cars - when you could actually hear the engine (unique sound for each car) and by doing so becoming aware if all things are OK or there is something wrong.
Body:
When one grabs an icon (file) with the LMB (left mouse button) and drags it to another location or surface, the file is moved or copied depending on it's location, after the user lets go of the mouse it can be seen that the file has been copied (the file is still in its orinal location and in the new location) or has been moved (the file has disapeared from its orinal location).
This poll is designed to give the community an opportunity to influence how the funds donated for the Haiku Code Drive 2008 program are allocated.
Which of the candidates and how many will be sponsored will be determined based on the results of this poll and the total funds donated by the community. A final announcement will be made on May 30.
This article is intended to explain in a nutshell how booting works in general, what the Haiku counterparts of standard boot process elements are and how to get everything together for a working boot in case this is not done automatically. These are things you will encounter installing/booting most operating systems, so it's not entirely Haiku specific.
