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.
* Remove support for VCSs other than git.
* Make the haiku-revision file a regular build target and make sure it
is built only once.
* Make determine_haiku_revision an actual shell script and simplify
it a bit.
Almost complete. bepdf is still missing, since it doesn't build with gcc
4 and a few source packages are missing as well (binutils and gcc
because haikuporter doesn't build them correctly ATM, mesa due to an
oversight).
* Introduce build variable HAIKU_IMAGE_ADDITIONAL_PACKAGES which can be
set to add additional packages to the image.
* Use HAIKU_IMAGE_ADDITIONAL_PACKAGES to support specifying a list of
additional packages via the build-package-list build profile action.
* Add htmldoc and texi2html when building the list of the packages for
which we need source packages when building the bootstrap Haiku image.
We don't want them on the regular image, but they are needed to build
some packages that are on it.
