* 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).
* This decouples the versions referenced by the architecture-specific
repository file from the actual versions available in the haikuports
branch that happens to be used for the bootstrap build.
* Before, we were putting both rigged and standard source packages
onto the bootstrap image, which caused the build to fail (because
non-rigged source packages can only be built with git available).
* Don't assume verdex as it isn't clear this was
occurring.
* Make an educated guess on HAIKU_BOOT_PLATFORM
based on provided board (but still allow it to
be overridden)
* Error out if user doesn't populate
HAIKU_BOOT_PLATFORM or enters an unknown board
name.
* You need to add "-sHAIKU_BOOT_BOARD=xxx" to
your jam to build for the proper ARM device.
* Rename beagle to beagleboneblk as per the
documentation.
HAIKU_* variables are copied to TARGET_*, making it possible to also
build for other targets (libbe_build, or BeOS R5 when we still allowed
that).
Thanks to Ingo for explaining how this is meant to work.
... mirroring home/config/non-packaged/
Also, sort the list lexographically and move the creation of the non-packaged
decorators directory from HaikuImage to HaikuImageCommon along with the rest.
* ArchitectureRules define a variable named HAIKU_ASFLAGS, so other
Jamfiles can append to it.
* But, TARGET_ASFLAGS was used instead in the single place where we
tried to make use of this (the verdex BoardSetup), and in the As rule
* Moreover, the As rule used $(architecture) instead of
$(TARGET_PACKAGING_ARCH) (I suspect a bogus copypaste?). So, it never
actually made use of the flags
With this working, add the proper flags to the BeagleBoard BoardSetup,
so we implement atomic operations the ARMv7 way (no need to syscall).
This helps with compiling, as the As and Cc/Cpp rules now agree on the
defines and the atomic implementation to use.
* As per the ML discussions. Bumps MIPS to tier 3.
* We've reached a unanimous descision that MIPS doesn't
target any real / valid hardware Haiku wants to pursue
at the moment. In the event that anyone wants to pursue
MIPS, feel free to fork Haiku into your own repository
(and we'll even link to it on the website ports page)
* If someone develops a viable plan for MIPS (and gets the
port working, it can be readded at a later date)
The ones with ARCH extension are used for setting up the KERNEL
ones, so no need to try and set both.
Also, the verdex target was not setting the ARCH one, and therefore
never configured gcc for ARMv5.
The new version breaks git, but only once it's in the repository.
Installing it manually alongside the old one works. Rebuilding git and
uploading a new package does not work, as for the package management,
the new version is exactly equal to the old, as the port revision isn't
newer. We need to come up with a proper way to handle this.
Also removes zsh, as that requires the new libpcre.
This is required on OS X and other systems which do not have the glibc
extensions for regular expressions (FreeBSD is not one of them as it
already includes gnuregex in /usr). With this there are no hardcoded
non-standard paths for OS X anymore.
regex.c and regex.h are from the official gnuregex 0.12 distribution,
the only modification is that I added __BEGIN_DECLS and __END_DECLS to
regex.h.
* Added cards need testing.
* 3dfx, ati, neomagic, and s3 still don't build due to some
more complex pointer size issues. (and I don't have hardware
to test on)
* as Ingo has pointed out, the remote user settings doesn't
relate to the build configuration at all, so setting the
remote user via HAIKU_REMOTE_USER in UserBuildConfig or
via shell environment is the way to go
* additionally: drop debug output
* add option --remote-user to configure, which sets HAIKU_REMOTE_USER
* add evaluation of HAIKU_REMOTE_USER variable when ssh-ing
into git.haiku-os.org
* HaikuRepository rule: Create the repository config.
* HaikuImage: Add the repository config for the Haiku image. The
repository cache is not added, though (it would only be available, if
the repository had been built before).
Implements #10287. The Haiku repository is now available in Haiku by
default.
Instead of the repository the URL can now be passed. It can use the
"$version" placeholder, which will be replaced by the content of the
given version file. If the URL is not given, the one from the repository
info will be used.
* PreprocessPackageInfo rule: Pull out new rule
PreprocessPackageOrRepositoryInfo which does the sed substituation and
optionally the filtering through the C preprocessor.
* HaikuRepository rule: Generate the repository info file (from the
given template). No longer do that in the build_haiku_repository
script.
Due to depending on dynamically built files, package files will always
be rebuilt when they are needed (e.g. when an image is built). The build
variable HAIKU_DONT_REBUILD_PACKAGES can be defined to prevent
rebuilding existing package files (even ones that are out-of-date).
Main target for this change is buildbot. We want to make sure that the
packages in the repository it builds are exactly identical to the ones
in the images, which may not be the case when the packages are rebuilt
(due to different timestamps of contained files). The respective build
order should be:
1. Build repository.
2. Without cleaning the generated directory, build different image types
with HAIKU_DONT_REBUILD_PACKAGES defined.
* Resolves problem with secondary arch builds
not picking up secondary os kit headers
* Still need to build x86 gcc packages
* No binary changes, shouldn't need a bootstrap
Older versions will not work anymore because of the API changes in
network kit (removal of nonstandard B_PROT_* status codes). x86 and
x86_64 packages have to be updated again.
This uses a variable CLANG that should be set to the Clang version. For
now, this has to be done manually (e.g. when invoking jam using jam
-sCLANG=34), but later, this will be auto-detected.
Work towards bug #10396
* Also update dependencies cmake and libxml2
* Bonus package: Milkytracker
This is for gcc2hybrids only. gcc4 and x86_64 users are welcome to
contribute an haikuwebkit package for their architectures using the
haikuporter recipe.
* Fix issue where mesa_devel attempted to lay
a symlink over a directory causing instability
installing mesa_devel
* Add mesa_swpipe to repos (LLVM enabled Gallium softpipe)
The introduction of secondary arch support for kernel files disabled
-Werror for all kernel files, since the -Werror flags were moved from
{CC,C++}FLAGS to TARGET_WARNING_{CC,C++}FLAGS_<arch>, which, however,
was overwritten by the SetupKernel rule. This commit introduces new
global variables {HAIKU,HOST,TARGET}_WERROR_FLAGS[_<arch>], which
contain the additional -Werror flags to be applied for the architecture.
The config variable WARNINGS can be set to "treatAsErrors" to cause
-Werror and {HOST,TARGET}_WERROR_FLAGS[_<arch>] to be appended to the
compilation flags.
Fixes#10280.
* Create new interface for cpuidle modules (similar to the cpufreq
interface)
* Generic cpuidle module is no longer needed
* Fix and update Intel C-State module
Somehow gcc doesn't detect the linker is GNU ld when run in Haikuporter.
We now force this in the recipe. This allows gcc to invoke the linker
with response files, avoiding "command line too long" errors, for
example when building WebKit.
* Fix adding WebPositive optional package.
* Fix adding wonderbrush package. Add it only for gcc2 to avoid a
warning by AddHaikuImagePackages.
* Simplify adding xz_utils package.
* Add rule HaikuRepository to build a repository from a repository info
file and a list of package files. It calls a build_haiku_repository
script which does all the work.
* Add target <repository>haiku for building the Haiku package
repository.
It should be built via "jam -q @alpha-raw build <repository>haiku";
the build profile is only needed to activate all build features.
We can't reliably set contemporary processors to an arbitrary frequency.
There are dependencies between cores and thechnologies like Turbo Boost
which may make actual frequency significantly different than the requested.
Moreover, it is the scheduler job to decide how much CPU performance is
needed and user shouldn't interfere with that.
In current state this driver is useless anyway. It's not MP safe.
The P-state values stored in hardcoded tables are only for processors
on which we can't use SpeedStep, because of lack of invariant TSC.
Proper driver should get P-states from ACPI, ensure that the CPU offers
invariant TSC and obviouslt be MP safe.
Some gristing mixup caused the non-secondary version of the lib to be
added to the non-secondary directory, which is what the main
architecture HaikuDevel is already doing.
* perl and python now support vendor-folders for modules and use correct
(i.e. writable) site-folders
* git, mercurial and scons have been adjusted to put their perl/python
modules into respective vendor-modules folders
* 'jam build-remote-test-repository' can now be used to create a
remote repository which will then be used by the build system,
such that the resulting package set can be tested.
Set HAIKU_CONTAINER_SYSTEM_DIR_TOKENS for the Haiku image to "system
non-packaged". All the rules using the variable would put stuff in
directories that will be read-only in the end (and aren't used anymore).
This way they can be used in UserBuildConfig.
* We are moving the HaikuPorts repositories over from haiku-files.org
to packages.haiku-os.org, and we will be creating new repositories
during a push hook from now on. As a result, only a small helper for
uploading new packages into the appropriate upload folder is required.
* Add build tool update_package_requires. Given a package info file and
a repository cache file, it updates the minimum versions of the
requires entries of the package info file according to what is
provided by the repository.
* PreprocessPackageInfo rule: Use update_package_requires (with the
HaikuPorts repository file).
When asked to strip binaries when copying to containers we now
strip to a temporary file, copy over resources to it, copy it
to the container, then copy the attributes from the original
source.
This should allow stripping binaries while preserving attributes
and resources even when copying to images.
We now only attempt to strip binaries, by detecting the
LINKFLAGS variable on the targets.
CopySetHaikuRevision now also forwards LINKFLAGS
to revisioned binaries.
Introduce separate AppendToContainerCopyFilesScriptStripFile actions
which are used for copying and stripping, and avoids many useless
shell tests.
When asked to strip binaries, they are detected and handled
individually for simplicity.
Note we still don't keep resources and attributes when stripping.
This makes it fit again.
We can't reference in BuildSetup a variable set with the other
ones in KernelArchitectureSetup since the rule is invoked later.
The developer building the packages should enter their own address
instead. I just noticed that a lot of the HaikuPorts package have a
packager attribute with the dummy address "The Haiku build system
<build-system@haiku-os.org>" due to the previous default value.
Currently only needed for boot floppy on some platforms.
Disabled for now.
Note we do not have a mean of knowing which file is a binary
or not so we just try to strip, and silently continue when
strip fails (like on the kernel settings file).
Also note strip actually replaces the file, which means it looses
both the resources and attributes, which shouldn't be a problem
for the boot floppy drivers archive, but is not wanted for other
images, so it's not usable elsewhere as such. Patch wanted.
* rule AddPackageFilesToHaikuImage: Add "flags" parameter. The only
supported flag is "nameFromMetaInfo". It causes the packages to be
copied under their canonical file name onto the image.
* Use the new flag for all generated packages save haiku_loader.hpkg.
* Add "flags" parameter and only supported flag "computeName". When
specified the "destName" argument is the name of a shell command
or function that will be called to determine the destination file
name when the container is built.
* AddFilesToHaikuImage: Pass flags to AddFilesToContainer.
Instead of listing all the objects we want from the libgcc archive
we just make a copy of it and remove those we don't want, and link
to it.
This should allow returning MAXLINE in jam to a sane value.
This makes package management operations that require a repository cache
immediately usable (even offline). Also makes sense for the
update-{all,packages} build profile actions, since those update the
repository config which would otherwise no longer match a potentially
existing cache.
... before copying the new contents to the image. This caters to the
typical use case of updating an existing Haiku, making manual
intervention to get the new packages activated unnecessary. The downside
is that manually added packages will be removed as well.
If additional parameters are specified, only those targets are built,
but under the influence of the build profile. E.g. "jam @alpha-raw build
haiku.hpkg" builds the package with SSL support, while "jam haiku.hpkg"
would build it without (unless explicitly enabled in UserBuildConfig).
* find_directory() and hard-coded paths use /boot/system instead of
/boot/common.
* The build system creates the writable directories in /boot/system
instead of /boot/common.
* The build system no longer installs any packages in /boot/common.
* This was a script relying on a working /etc/profile, which may not be
there
* Instead, use GNU which, available as an haikuport recipe
* Since the command does not seem to be needed for Haiku to run (and
also because I don't know how to do it), GNU which isn't in the default
install.
* Typing "which" in a terminal still works, as that uses an alias
defined directly in /etc/profile.
Declare a HOST_PTHREAD_LINKFLAGS variable to hold the flags
required to link with pthreads, and use it for the solver addon.
Works on GNU/Linux, please test and fix for other platforms.
* only the source package are actually relevant, as the source paths
within older versions of those source packages no longer match the
expectations of the build system
Latest gcc converts the old ones to the new ones anyway...
including when passing to gas, which of course is not new enough,
so we have to also force gcc to pass the old one around in one case.
Since the PM merge we now have way too many targets,
here jam clean just fails in execve() due to too long arguments.
jam clean is now very verbose but at least it works.
Another option could be to override the Clean rule itself
to clean in batch by splitting the list...
Patches welcome.
Both for the rPI and the Verdex target we now have FDTs. The verdex
DTS is homebrew, the pxa DTSIs come from Linux and should be kept
in sync.
The rPI DTS and Broadcom DTSI come from FreeBSD HEAD, and should
ofcourse also be kept in sync.
One global new Jam rule has been introduced for handling DTS
compilation, aptly named CompileDTS....
More coming!
This is especially important for the assembler code in the kernel,
since it enables workarounds for some critical errata related to
exception handling.
This adds the -mapcs-frame compiler flag for ARM to have "stable"
stack frames, adds support to the kernel for dumping stack crawls,
and initial support for iframes. There' much more functionality
to unlock in KDL, but this makes debugging already a lot more
comfortable.....
The symlink was only correct, if the container was a package. For
containers with a non-empty path to the system directory the link would
duplicate the system directory path.
* TARGET_KERNEL_PIC_FLAGS was probably meant to be
TARGET_KERNEL_PIC_CCFLAGS at the time this had been added in 2005.
As correcting the name would mean that kernel add-ons would be
compiled such that they wouldn't be position independent, dropping
the variable makes more sense (which is just a cleanup and doesn't
change anything due to that variable being always empty)
* The needed LLVM libraries are now within
the Mesa optional build package.
* The swpipe renderer needs some work still
and will likey change, swrast is fully
functional.
