* 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.
* 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.
* 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.).
