libalm.so is used by Stack & Tile as well as for the constraint-based
layout BALMLayout. This also adds libalm.so to the development package;
links it to /boot/system/development/lib.
* data files are still in the source tree.
* gutenprint headers contain a image.h header file which collides
with ours. This is solved by forcing include search first on
os/kernel directory.
* This solves the issue where libreadline wasn't actually linked to libncurses
* x86_64 update will follow later, as the build maxed out my x86_64 build VM
* Adjust the respective rules such that with disabled downloads, only
packages already available in the downloads folder will be considered
as available build features.
This way, the build system will not for instance try to build
<kdebug>qrencode after a bootstrap, as that package is not yet
available.
* If --no-downloads has been given, Haiku will be built without
trying to download anything, all required packages need to be put
into the download folder manually (the build will stop on missing
packages).
* As the required HaikuPorts repository can't be downloaded in this
mode, a local repository is created during the build, which only
contains the packages available in the downloads folder.
This is useful for building Haiku completely from source.
* The content of the preprocessed package-info files and the package
contents depend on the build type, so we use a different folder for
each build type.
Ideally, we would only need to set this in build/jam/board/*, but the
flags set there are not passed to the build of packages. The default is
using some early ARM variant, for which gcc lacks some more atomic
operations and emits calls to helper functions we don't implement.
Setting the default architecture avoids this, as all packages will now
be built to target the Cortex-A8.
Also set the proper VFP version in BeagleBoard config file.
Note this breaks the Verdex and Pi builds, but ARMv7 is what we should
focus on for now. We can try to make older archs work after finishing
the m68k port.
* This avoids mixup of the soft/hard float libs
* It also means we can use the hard-float libs for targets that supports
it
* Again, we could introduce an arm_softfp compiler for targets that
don't have floating point support, with a different gcc build.
