* Cleanup the SD card image building to allow jam -q @bootstrap-mmc to
work.
There are a few remaining tricks before you can safely build an image:
* This uses a non-POSIX du option, and is only tested with Linux du
only (Linux is the only supported system to run bootstrap builds,
anyway)
* The Python recipe in haikuports.cross is known to not build on
Debian/Ubuntu, but work fine on OpenSuse. There is a patch available in
haikuports bugtracker to allow the reverse.
* You need to populate the haikuports repo package list with some
packages (which don't exist yet) to make the build system happy. But our
git hook to generate the repositories is preventnig me to share this
hack.
Once built, the image currently crashes early in the kernel execution.
On to debug that!
* That change did not make any sense, as the floppy-boot images
can't be built in debug mode anyway (the result is much too large).
This reverts commit 911821275a.
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.
* qrspec.h isn't yet part of the package for some reason.
* removed qrencode from the bootstrap package.
* only include qrencode when the qrencode package is found.
* didn't check qrencode itself, tests welcome.
These are used when an app uses BMediaFile/BMediaTrack, which leads to
the plug-ins being instanciated on the application side.
* Fixes one more part of #10049 (media add-ons are still missing).
* Will probably not solve any real-world issue because of #4893.
* Instead of separate variables, HAIKU_BUILD_TYPE is set to one of
'bootstrap', 'minimum' or 'regular'.
* Adjust uses of HAIKU_BOOTSTRAP_BUILD accordingly.
This reverts commit 4a4e2dae77.
It broke the build with:
Resolving package dependencies ...
Encountered problems:
problem 1: nothing provides cmd:as>=2.23.2_2013_04_09 needed by
gcc-4.8.2_2014_01_28-2
solution 1:
- allow deinstallation of gcc-4.8.2_2014_01_28-2
Instead, the fixed binutils package should be used. Reverting this now
as otherwise it's not even possible to build a system to build a fixed
package.
* Move actual definitions of respective image contents to files
underneath build/jam/images/definitions (minimum, bootstrap, regular).
* HaikuImage now only includes the image definitions for the selected
build profile and adds the Haiku packages.
* Simplified topmost Jamfile to some extent.
* Move definition of DESKBAR_APPLICATIONS and DESKBAR_DESKTOP_APPLETS
from build/jam/packages/Haiku to the respective image definition file.
* Sort and reformat several lists to make them more readable.
* Add new build profile 'minimum', which defines a minimum set of
packages.
* Introduce HAIKU_BOOTSTRAP_SOURCES_PROFILE and let it default to
'@minimum-raw'. This can be overruled in UserBuildConfig, setting
it to '@release-raw' will cause all source packages required for a
full release to be put onto the bootstrap-image.
* Add new image HaikuImageMinimum, which is meant to define the minimum
useful Haiku image (yeah, I know that's vague).
* Add HAIKU_MINIMUM_BUILD, which indicates that HaikuImageMinimum should
be used (it would be better to merge this with HAIKU_BOOTSTRAP_BUILD
into something like HAIKU_BUILD_TYPE)
* Cleanup duplicate references to basic packages - those are now added
by the topmost Jamfile (no longer referenced by the build profiles).
