* Also make use of new build feature rules.
* Since the hacky long_jump_buffer field has been removed from the
jpeg_error_mgr struct in the new package, the structure is now
wrapped in the JPEGTranslator code to achieve the same behavior.
We have to use actual targets that cause the respective download and
extract the packages. Otherwise the build fails when the packages
haven't been extracted yet.
Missed that when adding the script. Therefore it would be created in the
current directory and when building multiple packages concurrently the
script would be overwritten.
The new configure option "--use-xattr-ref" enables an xattr assisted
variant of the generic attribute emulation. Instead of using the inode
ID of a node to identify its attribute directory, we use a reasonably
unique random 128 bit number, which we generate and attach as an
attribute to the node. This way, when a node changes its inode ID
(defragmentation?) or the inode ID of a removed node with a left-over
attribute directory is reused, attributes won't get mixed up.
The old method is still used for symlinks (since on Linux only
priviledged users can write attributes on symlinks), but those usually
only have a rather boring BEOS:TYPE attribute, so mix-ups wouldn't be
that problematic anyway.
* this package wraps the haiku_cross_devel package (i.e. it contains
that package in /develop/cross)
* the wrapper package is meant to be installed into the system
hierarchy, from where haikuporter will fetch the contained package
when needed
* add HAIKU_PACKAGING_ARCH, which is set to the target packaging
architecture
* introduce support for generic package infos, which are package infos
that are the same for all architectures, except for the declaration
of the package architecture itself
* move package info files underneath architecture-specific or generic
folder
* BuildHaikuPackage rule: Create the script that contains the extraction
commands.
* build_haiku_package: Add extractFile() function (stripped down version
from build_haiku_image).
In build_haiku_image the functionality was mainly used to extract the
optional packages, which is no longer done. We still need it e.g. for
the Wifi firmware packages that want to be extracted.
* Add new package haiku_loader.hpkg and move haiku_loader there. The
package is built without compression, so that the stage 1 boot loader
has a chance of loading it.
* Adjust the stage 1 boot loader to load the haiku_loader package and
relocate the boot loader code accordingly.
It allows to control the compression level used for package creation
and update. The default (9) is *very* slow, so developers may want to
use a smaller level during the regular development process to keep
turn-around times low.
* add vesa.accelerant, vesa driver, ps2, isa, bios, generic_x86 for x86_64 too
* only have reiserfs, firewire, agp_gart targets for x86
* reverted hrev43950, liblocale alias shouldn't be needed anymore
This means the build tools will no longer be built against the host
platform's libbe, which avoids compatibility problems -- e.g. an
older Haiku host libbe may not have certain features the build tools
require -- and also makes the build behave more similiar on Haiku and
other platforms. The host libroot dependency still remains and is not
easy to get rid of.
Also remove some bits of BeOS/Dano/Zeta build support.
* Update MimeSet rule to use the MIME DB the build system creates.
* Add CreateAppMimeDBEntries rule and call it from Link for targets that
might be applications that need to be registered with the MIME DB. For
the target the rule is invoked with it creates a directory into which
the entries for the types to be registered are written. The directory
is associated with the target via the HAIKU_MIME_DB_ENTRIES variable.
* AddFilesToContainer: If a target is added that has MIME DB entries,
also add those to the container.
* build_haiku_package: Call mimeset for the package contents.
Since the same driver can be added in more than one category, in a few
cases AddDriversToContainer was invoked twice for the same target. Avoid
adding the driver twice to add-ons/kernel/drivers/bin in such a case.
Didn't really cause any problem, but no need to copy the file twice.
