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.
If for some reason (e.g., a forced rebuild), Buildbot rebuilds the same hrev,
it was possible for the scp command to place the repositoryDir as a subdir
in $arch/$version/, instead of as $arch/version. This should ensure that the
contents of repositoryDir are placed in $arch/$version/.
* 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.
Resolving the package dependencies for system might yield packages that
are already given for common. Filter those out of the list for common
before resolving the common dependencies.
* IsPackageAvailable, FetchPackage: Add flags parameter. The only
flag supported ATM is nameResolved, indicating that the specified
package name does not need to be resolved with respect to a secondary
architecture anymore.
* Add build profile action "build-package-list". As an argument the
file to which the list of all packages needed for the image is
written. The rule BuildHaikuImagePackageList implements the action.
* BuildBootstrapRepositoryConfig: Does now require the variable
HAIKU_REPOSITORY_TREE_PATH to be set on the config file target instead
of hard-coding the path. Allows reuse of the actions.
* Add rules BuildHaikuPortsSourcePackageDirectory and
BuildHaikuPortsRepositoryConfig. The former builds all HaikuPorts
source packages needed to build the packages for an alpha image. The
latter generates a haikuports.conf file for use on the bootstrap
Haiku.
* HaikuImageBootstrap: Add directory /boot/home/haikuports which
contains a subdirectory with the source packages and a
haikuports.conf.
The Haiku bootstrap image is now built with (hopefully) all required
primary and secondary architecture packages. The runtime loader is still
resisting our wish to run secondary architecture programs, though.
For the secondary architecture the same specified package name means a
different package, so we need to use the mapped name IsPackageAvailable
returns.
* Add rule FSplitPackageName. It splits a package name into port name
and package suffix.
* FSetConditionsHold: Rename to FConditionsHold and replace the set
parameter by a predicate rule parameter, thus adding more flexibility.
* FIsBuildFeatureEnabled: Use the faster check.
* Add rule FQualifiedBuildFeatureName. Given a build feature name, it
prepends the current packaging architecture to yield a qualified
feature name. Is used by the other build feature rules so that the
same build feature can be configured differently for each arch.
* ExtractBuildFeatureArchives: The supplied list is now filtered via
FFilterByBuildFeatures, allowing for build feature conditions in the
list.
* Add rule InitArchitectureBuildFeatures. It is called early for each
configured architecture, setting up some basic build features for it.
"primary" is set for the primary architecture and a "secondary_<arch>"
is set for each secondary architecture.
* BuildFeatures: Add secondary architecture support: Use the correct
paths for libraries and headers (subdir for secondary architecture)
and configure the icu and zlib sources only for the primary
architecture.
* BootstrapPackageRepository: The package lists are now filtered via
FFilterByBuildFeatures, allowing for build feature conditions in the
lists.
* IsPackageAvailable, FetchPackage: Add secondary architecture support.
* HaikuPortsCross/x86_gcc2: Add icu and zlib x86 secondary packages.
The second stage Haiku cross devel package for the secondary
architecture can now be built.
Pass --enable-hybrid-secondary to gcc's configure when building it as
a secondary compiler. Doesn't make a difference for building Haiku
itself, but makes it easier to match the Haiku cross devel package with
the compiler when building bootstrap packages with haikuporter.
gcc 4 only ATM.
* Libraries for a secondary architectures must be placed in a respective
subdir.
* Add a suffix to the package name when building for a secondary
architecture. Looks a bit weird
("haiku_cross_devel_sysroot_x86_gcc_x86.hpkg"), but is consistent.
* All packaging architecture dependent variables do now have a
respective suffix and are set up for each configured packaging
architecture, save for the kernel and boot loader variables, which
are still only set up for the primary architecture.
For convenience TARGET_PACKAGING_ARCH, TARGET_ARCH, TARGET_LIBSUPC++,
and TARGET_LIBSTDC++ are set to the respective values for the primary
packaging architecture by default.
* Introduce a set of MultiArch* rules to help with building targets for
multiple packaging architectures. Generally the respective targets are
(additionally) gristed with the packaging architecture. For libraries
the additional grist is usually omitted for the primary architecture
(e.g. libroot.so and <x86>libroot.so for x86_gcc2/x86 hybrid), so that
Jamfiles for targets built only for the primary architecture don't
need to be changed.
* Add multi-arch build support for all targets needed for the stage 1
cross devel package as well as for libbe (untested).
The goal is to do hybrid builds in a single jam (instead of calling a
sub-jam to build parts with the secondary tool chain). This changeset
adds support to configure to prepare multiple tool chains.
configure:
* Merge option --build-cross-tools-gcc4 into --build-cross-tools. The
option does now always require a packaging architecture parameter,
i.e. x86_gcc2 for the legacy tool chain.
* Multiple occurrences of the --build-cross-tools and
--cross-tools-prefix options are allowed. The first one specifies the
primary tool chain, the subsequent ones the secondary tool chains.
* All architecture dependent jam variables are now suffixed with the
name of the packaging architecture. The new HAIKU_PACKAGING_ARCHS
contains the packaging architectures for the prepared tool chains. The
first element is for the primary tool chain.
* No longer generate a separate libgccObjects file. Just put the
respective variable into BuildConfig as well.
build_cross_tools[_gcc4]:
* Replace the <haiku output dir> parameter by a <install dir>
parameter. This allows to create different cross-tools directories.
They are simply suffixed by the packaging architecture.
Jamrules:
* For the moment map the variables for the primary tool chain to the
respective suffix-less variables, so that everything still works as
before.
The next step is to actually support the secondary tool chains in the
jam build system. This will require quite a bit more butchering, though.
* Don't handle the bootstrap case in the main Jamfile. Add all bootstrap
packages to the image in the profile definition. That's less
confusing, hopefully.
* Add the missing bootstrap packages (ncurses*, libtool_libltdl). The
would normally be added in build_haiku_image when the package
dependencies are resolved, but we don't do that for the bootstrap
image, since we intentionally leave some dependencies out (e.g. perl)
because they can be built.
* Add configure option --bootstrap which allows specifying the
haikuporter and HaikuPorts repository paths.
* Add rules for supporting a second repository type. The
PackageRepository rule is now private and RemotePackageRepository is
used for remote repositories. The new BootstrapPackageRepository rule
is for defining a bootstrap repository (there will probably be only
the HaikuPorts cross repository) whose packages can be built as needed
via haikuporter.
* Rename DownloadPackage to FetchPackage.
* Define repository HaikuPortsCross.
* HaikuCrossDevel package(s): There are now two sets of packages: A
"stage1" set with the same content as before and a final set
additionally containing the libraries libbe, libnetwork, libpackage.
Those are needed for building the libsolv bootstrap package while for
building them we need other bootstrap packages (ICU, libz).
This is basically all that's required to build a bootstrap Haiku
completely from sources, with a few caveats:
* There's no ICU bootstrap recipe yet (so one has to cheat and use the
prebuilt package ATM).
* Probably doesn't work on Haiku yet (tested on Linux only).
* A 32 bit environment must be used (otherwise building the gcc 2
bootstrap package fails).
* Building with multiple jobs doesn't work yet, since haikuporter uses
common directories for building different packages and there's no
explicit serialization yet.
* Haven't tested the resulting image save for booting it. So it probably
needs a bit more work before it can actually build the final
HaikuPorts packages.
DefaultBuildProfiles is now included earlier (right after BuildSetup).
This allows us to set HAIKU_BOOTSTRAP_BUILD earlier, so it can be used
for the repository selection. The actual build profile definitions,
which cannot be done that early, live in the rule
DefineDefaultBuildProfiles, which is invoked where the file was
previously included.
Add support for placeholders in the attribute values. The values of the
currently supported placeholders depend on the package file name
(package version, actual package and port name, etc.).
Also, pre-process all package infos (not only the generic ones) and
define the macro HAIKU_BOOTSTRAP_BUILD, if building a package for a
bootstrap image.
Copy:
* packages: Haiku -> HaikuBootstrap
* images: HaikuImage -> HaikuImageBootstrap
... and remove some unncessary content.
Setting the jam variable HAIKU_BOOTSTRAP_BUILD enables using the
bootstrap files.
* Under the base URL there are supposed to be the repository files and a
subdirectory "packages".
* Fix the repository URL related confusion introduced earlier. The URL
in
the repository info (and thus in the repository file) is supposed to
be the base URL for the repository. It is not a (potentially)
different base URL for the package files. Package and repository
files were supposed to live in the same directory. Now, by requiring
the package files to live in a subdirectory -- which can also be a
symlink -- we gain some flexibility.
The URL in the repository config is usually the same as the in the
repository info, unless it refers to a mirror site. This allows for
mirrors to copy the original repository verbatim.
* Remove the PackageURL rule and introduce a DownloadPackage rule
instead. The URL for a package file cannot be computed in the jam
parsing phase anymore, as it contains the hash value of the package
list.
* BRepositoryConfig: Add PackagesURL() for convenience.
The package kit actually requires the files "repo", "repo.info",
"repo.sha256" to be located under the repository base URL, so the
approach to name the repository file "repo-<hash>" doesn't work.
Now there's a directory "<hash>" which contains the files.
This commit moves the computation of the hash and downloading the
repository file from the build_haiku_image script to the jam build
system. The repo.info is also downloaded and a repository config file
is generated.
* Build libsolv and the dependency solver part of the package kit for
the build platform.
* Add build tool get_package_dependencies. Given a list of package files
and a list of repository files it determines the additional packages
that need to be retrieved from the repositories and prints their URLs.
* Add rules to work with external repositories in the build system
(build/jam/RepositoryRules):
- PackageRepository declares an external repository with all its
packages. The URL of the repository file isn't specified. It is
computed from a given base URL and the SHA256 hash of the list of
package files.
- GeneratedRepositoryPackageList generates a file containing the file
names of all packages in a repository.
- IsPackageAvailable returns whether a package is available in any
repository.
- PackageURL returns the URL for a package.
* Declare the HaikuPorts repository for x86_gcc2
(build/jam/repositories/HaikuPorts/x86_gcc2).
* Add rule AddHaikuImagePackages to add a package to the image and rule
IsHaikuImagePackageAdded to determine whether a package has been
added.
* OptionalPackages: Remove all entries that just downloaded and
installed an external package. AddHaikuImagePackages can be used
instead and is used in the remaining entries. Also move the remaining
optional package dependency declarations from
OptionalPackageDependencies here.
* ExtractBuildFeatureArchives: Instead of the URL parameter a package
name must be specified now. This allows to simplify BuildFeatures
significantly, since there's no dealing with URLs anymore. "if" out
the entries that aren't supported yet.
* build_haiku_image: For the packages installed in system and common
resolve their dependencies and download and install them as well.
* ExpanderSettings: Use a settings directory "expander" and rename
settings file to "settings".
* ExpanderRules: Read expander rules from "rules" files in the settings
directory, then from files in expander/rules subdirectories of the
installation location data directories, and finally add the built-in
rules. This allows packages to provide expander rules (as already
done by the p7zip package).
* OptionalPackages: Remove AddExpanderRuleToHaikuImage invocations.
* ImageRules: Remove Expander rule file related rules.
* Deskbar now uses ~/config/settings/deskbar/menu_entries for its menu,
falling back to /system/data/deskbar/menu_entries, when the former
doesn't exist. The latter always exists and is a virtual directory
merging the deskbar/menu subdirectories of ~/config/settings/ and
<any installation location>/data/. So, if a package provides a
deskbar menu symlink, it is added automatically when the package is
activated. The user can add own menu items by putting stuff into
~/config/settings/deskbar/menu/, only use their own organization by
symlinking it to menu_entries, or do fun stuff by making menu_entries
a customized virtual directory.
* HaikuImage: No longer create any deskbar menu symlinks in the user's
settings directory. Instead add them to the Haiku package.
* OptionalPackages: At least for the optional packages that do have
hpkgs, no longer create deskbar menu symlinks in the user's settings
directory.
* Move all Deskbar settings files to ~/config/settings/deskbar/ and
drop the "Deskbar_" prefix.
* at least for gcc2, we used to leave the 'os' subfolder in there,
which may have caused problems when Haiku's headers have changed
since the last time the compiler was built.
(cherry picked from commit 92bb2fb33e)
* force creation of a cross-compiler for both gcc2 and gcc4 when
building on Haiku (by suffixing the build and host machine with
'_buildhost')
(cherry picked from commit df69e209bb)
Conflicts:
build/scripts/build_cross_tools_gcc4
* at least for gcc2, we used to leave the 'os' subfolder in there,
which may have caused problems when Haiku's headers have changed
since the last time the compiler was built.
* 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.
* After examining MacOS toolbox roms, I think i've got
this nailed down. The MacOS Toolbox rom contains chrp
code at the top and binary code at the bottom.
* The Raw format for the chrp seemed to cause issues with the
OpenFirmware boot process on some systems. NetBSD uses a '-'
file type.
* The format of the chrp seems a lot more sensitive across machines
than described. Ensure our returns and spaces are even.
* Booting with the 'c' key is still working on my older OpenFirmware
machine with the chrp script. The bitmap logo is a half black, half
white box.
* I removed the &device; alias for now for troubleshooing. It also may
of been causing compatibility issues. More testing is needed.
* It seems like not all NewWorld OpenFirmware
versions support booting from CHRP scripts.
* Move Haiku elf bootloader into bootloader.b
type tbxi. As it is in the blessed directory
it is picked up by cd:,\\:tbxi
* Adjust bootinfo.txt to point to bootloader
&device; ensures that the image can be started
regardless of source media
* Adjust bootinfo.txt to use \\ as base. \\ is an
alias for the blessed folder on the boot media
* Rename ofboot.b to ofboot.chrp to avoid confusion
* Add .txt, .html to hfs.map to identify them properly
* The haiku-boot-cd-ppc.iso now boots on my G3 PowerBook
by holding the 'c' key at startup. The boot menu colors
are incorrect (white background) but it is a step in
the right direction.
* New chrp script. Blank icon for the moment, if someone
could figure out how to make a chrp icon that would be
neat.
* Tested working on qemu and real hardware. Need to test
on a more modern PowerPC Mac however.
* 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
