build/jam: Inline HOST_ADD_BUILD_COMPATIBILITY_LIB_DIR where possible.

The "exec" tool can only handle one command with environs set at
the beginning of the line, so now we set the ADD_BUILD_COMPAT...
in this format. This also seems to be a general performance
improvement to builds using real shells, too.

Change-Id: If4b3117651b5475039d5e8116cd3de398582290a

RepositoryRules: Error when the just-built package does not exist.

This will make version mismatches between the bootstrap repository
and the haikuports.cross repository more apparent.

Fix missing absolute dir.

The variable is used after a "cd" so it must be absolute.

Change-Id: I8d591b8642179603249ac56a1fcac082f29c870c
Reviewed-on: https://review.haiku-os.org/c/1387
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

RepositoryRules: fix typo

This went through review too fast, the wrong variable name was used so
the package name was not listed...

Change-Id: I81d4aa57fdb65297ae9f63ebf123d7a6395a99b6
Reviewed-on: https://review.haiku-os.org/c/1109
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

bootstrap: a little more explicit error if things are wrong

There seems to be a problem with the way we set the gcc_bootstrap
package build to depend on the bootstrap package with haiku headers.
If said package cannot be built (for example some definitions are
missing for a new architecture), we end up passing an empty string as
the package to use to haikuporter.

The error message given by Haikuporter is confusing, and not easy to
investigate. So, intercept the error earlier to save time for the next
person to hit this problem.

Change-Id: I64f326e5cb3bb0d44632864ad38ad10bb88d0c7b
Reviewed-on: https://review.haiku-os.org/c/1082
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

build: Fix paths of tools for bootstrap builds.

The paths to tools are relative to cwd, and HAIKU_ABSOLUTE_OUTPUT_DIR is
not necessarily the same as that, in the case where jam is invoked from
the repository root instead of a "generated" directory.

HOST_OBJECT_BASE_DIR is relative to pwd also, so just make it absolute.

Change-Id: I2aef83804be31c3c03c8577d56372f2dc6cb77f8
Reviewed-on: https://review.haiku-os.org/718
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

Revert "RepositoryRules: Use absolute output path for bootstrap package,mimeset,mimedb"

* Nope. Double generated directories when bootstrap run from HAIKU_TOP
* Third time's a charm?

This reverts commit 3db452372c187ff50208c380d2184fd813cec23a.

RepositoryRules: Use absolute output path for bootstrap package,mimeset,mimedb

* First re-fix of what was reverted in 85f8e7001
* haikuporter calls these during bootstrap and needs absolute paths

Change-Id: I40f1b15ffd474d3286356f3151eacd9a4a09add2

Revert "jam: Fix bootstrap via absolutes in LD_LIBRARY_PATH"

This reverts commit 030d0eb58f0fae4201afcb83a38ac70038393b8d.

It is absolutely not correct to assume PWD is the generated dir;
it may also be the repository root.

Fixes jam putting some build artifacts in the source tree.

jam: Fix bootstrap via absolutes in LD_LIBRARY_PATH

* The PWD's are live based on jam run location which means
they shouldn't bind the generated directory to a fixed path
as before.
* We also need an absolute LD_LIBRARY PATH since haikuporter
loses the context invoking host tools.
* I don't think we can run jam from outside of the generated
directory anymore... but I don't think that was a thing.

Change-Id: I020f902ce5235bf268c9075d6e2ae85296a4ad20

bootstrap: Fix bootstrap after HAIKU_TOP changes

* haikuporter's cwd is the haikuporter path during execution
(haikuporter/HaikuPorter)
* We have to pass the full working path and can't use a relative
path here
* Seems to fix the bootstrap build

Change-Id: Ibb139f164c5e08eda3a08136c4e9ea2c9eaeae9e

RepositoryRules: correctly handle multiple secondary archs.

RepositoryRules: Restore mistakenly deleted local variable.

RepositoryRules: Do not use the downloaded repo.info.

Instead build the one in-tree from src/data/package_infos/. Fixes the
"HaikuPorts repos have wrong URL" problem that has occured since the
switch to buildmaster repos.

RepositoryRules: RepositoryConfig does not need/use URL now.

build: Remove now-defunct jam commands.

build: Cleanup and fixes following previous commits.

* Hashing semantics for the new build repositories are different than
the old ones, so update those (if the x86 build was not broken before
it is now...)
* OptionalPackages has been updated slightly (removed libtool and git_cvs
from the default images, as they are rarely used nowadays and would pull
in a bunch of dependencies we don't really care for either)
* Removed lib:libqrencode from Haiku package requires (qrencode_kdl is a
static library, the userland libqrencode is not used anywhere in the tree,
as far as I can tell)
* Fix build of JPEG2000 translator after update
* Decouple fluidsynth build machinery and remove from image now that it
is no longer used
* Update repository URL in Repositories preflet

bootstrap: Fix behaviour after default haikuporter mode change

Revert "repo rework: Re-add compatibility url field"
Revert "repo rework: Remove stubs; Breaks repo compat."
Revert "repo rework: Remove need for repos to be self-aware"

This reverts commit a2b2f4d6427914cdcdb59943dd8e4a0bfdcd53ee.
This reverts commit 602076ef82647a48fd10f4d1ec830bb4242f9eb6.
This reverts commit 5ffaf72c8a74a7eb6827e4d2b1f47c9360ddaefe.

These changes break the build on Haiku and the ability to create repo
mirrors, for the lack of a replacement for the URL (an UUID was evoked
on the mailing lists, but not implemented).

We are due for a release soon, please don't break the build.

repo rework: Remove need for repos to be self-aware

* See #12917 for details.
* Squashed to one commit to make revert easy if we
run into any issues.
* pkgman is now pre-attached to the 'current' repo
version within nightly images so they can be updated
by default.
* This shouldn't impact us keeping older sets of package
versions by commit hash for building older hrevs.
* There are XXX stubs with "Kill me". These will need
to be dropped after users are given sufficent time to
upgrade. We're dropping a previously required field (url)
so making this a slowish roll out.
* Makes the repos a lot less restrictive which should
help PM package building automation be a bit easier.
* Once this stuff smooths out, we'll add UUID's to the
repo definitions for duplicate repo detection.

configure: Add variable to see if we're bootstrapping

Fix (hopefully) bootstrap build with HAIKU_NO_DOWNLOADS=1

* With HAIKU_NO_DOWNLOADS=1, the check against existing package files
in the download folder should only be done in the phase that is
adding packages to be put onto the resulting target image, not in the
phase that is adding the bootstrap packages (as here those packages
will be *built*, not downloaded).

Introduce stage0 into the bootstrap process.

* This stage builds the gcc packages to get the shared syslibs, which
only requires the Haiku glue code.
* Add separate declaration section for stage0 packages to
HaikuPortsCross repository files.
* For the bootstrap_stage0 platform, fall back to the gcc headers
provided by the cross-compiler.

Simplify handling of package names.

* No longer apply somewhat crude mechanism for converting a package name
into a corresponding port name - haikuporter by now supports package
names directly.

This fixes a problem when trying to pass 'gcc_syslibs_devel' to
haikuporter, which only ever saw 'gcc_syslibs'.

Add more missing 'local's to variable declarations.

Improve IsPackageAvailable()

* When adjusting the package name for the secondary architecture,
it is unclear where exactly in the package name the architecture
specifier is. To remedy, we try all possible positions until
we find the package (or there are no other possibilities).

Put haiku repository onto image.

* Now that system updates seem to work properly, put the haiku
repository config and cache file onto the image automatically.
* Adjust URL of haiku repository (it is currently redirected
to some other URL at download.haiku-os.org, but that will be
changed later).

Use a specific packager for continuous integration builds.

Add HAIKU_PORTER_EXTRA_OPTIONS variable.

* This can be used to add arbitrary options to invocations of
haikuporter.

Improve build feature handling with HAIKU_NO_DOWNLOADS=1

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

Add new configuration option --no-downloads.

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

Whitespace cleanup in root and 'build' folder.

* Removed trailing whitespace and empty lines at top of files.

RepositoryRules: Add option to now download any packages

This is useful if Haiku should be built using self-built packages.

Replace HAIKU_{BOOTSTRAP,MINIMUM}_BUILD with HAIKU_BUILD_TYPE.

* Instead of separate variables, HAIKU_BUILD_TYPE is set to one of
'bootstrap', 'minimum' or 'regular'.
* Adjust uses of HAIKU_BOOTSTRAP_BUILD accordingly.

Drop extra packages and note which no longer applies.

* now that haikuporter resolves the dependencies correctly, there's no
need to add texi2html and htmldoc explicitly

Make set of source packages for bootstrap-image configurable.

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

Fix creation of haikuports.conf for bootstrap image.

* comments in here-documents don't work (the shell filters them out),
so we echo the comment line explicitly

Drop --remote-user configuration option again.

* 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 support for specifying remote ssh login user.

* 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

Add repository config for the Haiku repository to the image

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

RepositoryConfig rule: Make a bit more generic

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.

Move creating the Haiku repo info to jam

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

Replace missed alpha-raw release build profile occurrences

Add target for building a Haiku package repository

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

RepositoryRules: Automatic whitespace cleanup

Reintroduce jam rule for creating remote repository for testing.

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

Replace jam build-remote-repository with jam upload-packages

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

Bootstrap image haikuports.config: Comment out PACKAGER

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.

added a check for HOST_EXTENDED_REGEX_SED presence

Fix bashisms

Besides, at least one test was probably incorrect,
trying to match /* with a single = in [[.

Added new jam command 'build-remote-repository'.

* build-remote-repository <packages> uploads the given set of packages
to the server and builds the remote repository

Handle rigged source packages when determining port name.

* I'm not sure this makes much of a difference, but I thought it's
better to play it safe.

Bootstrap Haiku image: add source for more required packages

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

Add build variable HAIKU_PORTER_CONCURRENT_JOBS

It can be set to the number of jobs specified on the haikuporter
command line. Speeds up the bootstrap build quite a bit.

Adjust to renamed option of haikuporter.

bootstrap image: build needed source packages and add them

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

Fix two problems when building without secondary architecture.

build features/bootstrap repo: support secondary arch

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

More work towards hybrid support

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

BootstrapPackageRepository: serialize package creation

Since haikuporter uses a common directory for building the ports, we
can't build them concurrently. This makes jamming with multiple jobs
safe again.

Integrate building the HaikuPorts bootstrap packages

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

rule AddRepositoryPackages: add debugInfoPackage parameter

It works just like the sourcePackages parameter.

Change repository directory layout

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

Adjust to changed HaikuPorts repository layout

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.

GeneratedRepositoryPackageList: defeat localization

Set LC_ALL=C, so "sort" produces useful results.

Switch build system from optional package to repositories

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

configure: Add variable to see if we're bootstrapping

Fix (hopefully) bootstrap build with HAIKU_NO_DOWNLOADS=1

* With HAIKU_NO_DOWNLOADS=1, the check against existing package files
in the download folder should only be done in the phase that is
adding packages to be put onto the resulting target image, not in the
phase that is adding the bootstrap packages (as here those packages
will be *built*, not downloaded).

Introduce stage0 into the bootstrap process.

* This stage builds the gcc packages to get the shared syslibs, which
only requires the Haiku glue code.
* Add separate declaration section for stage0 packages to
HaikuPortsCross repository files.
* For the bootstrap_stage0 platform, fall back to the gcc headers
provided by the cross-compiler.

Simplify handling of package names.

* No longer apply somewhat crude mechanism for converting a package name
into a corresponding port name - haikuporter by now supports package
names directly.

This fixes a problem when trying to pass 'gcc_syslibs_devel' to
haikuporter, which only ever saw 'gcc_syslibs'.

Add more missing 'local's to variable declarations.

Improve IsPackageAvailable()

* When adjusting the package name for the secondary architecture,
it is unclear where exactly in the package name the architecture
specifier is. To remedy, we try all possible positions until
we find the package (or there are no other possibilities).

Put haiku repository onto image.

* Now that system updates seem to work properly, put the haiku
repository config and cache file onto the image automatically.
* Adjust URL of haiku repository (it is currently redirected
to some other URL at download.haiku-os.org, but that will be
changed later).

Use a specific packager for continuous integration builds.

Add HAIKU_PORTER_EXTRA_OPTIONS variable.

* This can be used to add arbitrary options to invocations of
haikuporter.

Improve build feature handling with HAIKU_NO_DOWNLOADS=1

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

Add new configuration option --no-downloads.

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

Whitespace cleanup in root and 'build' folder.

* Removed trailing whitespace and empty lines at top of files.

RepositoryRules: Add option to now download any packages

This is useful if Haiku should be built using self-built packages.

Replace HAIKU_{BOOTSTRAP,MINIMUM}_BUILD with HAIKU_BUILD_TYPE.

* Instead of separate variables, HAIKU_BUILD_TYPE is set to one of
'bootstrap', 'minimum' or 'regular'.
* Adjust uses of HAIKU_BOOTSTRAP_BUILD accordingly.

Drop extra packages and note which no longer applies.

* now that haikuporter resolves the dependencies correctly, there's no
need to add texi2html and htmldoc explicitly

Make set of source packages for bootstrap-image configurable.

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

Fix creation of haikuports.conf for bootstrap image.

* comments in here-documents don't work (the shell filters them out),
so we echo the comment line explicitly

Drop --remote-user configuration option again.

* 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 support for specifying remote ssh login user.

* 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

Add repository config for the Haiku repository to the image

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

RepositoryConfig rule: Make a bit more generic

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.

Move creating the Haiku repo info to jam

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

Replace missed alpha-raw release build profile occurrences

Add target for building a Haiku package repository

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

RepositoryRules: Automatic whitespace cleanup

Reintroduce jam rule for creating remote repository for testing.

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

Replace jam build-remote-repository with jam upload-packages

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

Bootstrap image haikuports.config: Comment out PACKAGER

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.

added a check for HOST_EXTENDED_REGEX_SED presence

Fix bashisms

Besides, at least one test was probably incorrect,
trying to match /* with a single = in [[.

Added new jam command 'build-remote-repository'.

* build-remote-repository <packages> uploads the given set of packages
to the server and builds the remote repository

Handle rigged source packages when determining port name.

* I'm not sure this makes much of a difference, but I thought it's
better to play it safe.

Bootstrap Haiku image: add source for more required packages

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

Add build variable HAIKU_PORTER_CONCURRENT_JOBS

It can be set to the number of jobs specified on the haikuporter
command line. Speeds up the bootstrap build quite a bit.

Adjust to renamed option of haikuporter.

bootstrap image: build needed source packages and add them

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

Fix two problems when building without secondary architecture.

build features/bootstrap repo: support secondary arch

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

More work towards hybrid support

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

BootstrapPackageRepository: serialize package creation

Since haikuporter uses a common directory for building the ports, we
can't build them concurrently. This makes jamming with multiple jobs
safe again.

Integrate building the HaikuPorts bootstrap packages

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

rule AddRepositoryPackages: add debugInfoPackage parameter

It works just like the sourcePackages parameter.

Change repository directory layout

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

Adjust to changed HaikuPorts repository layout

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.

GeneratedRepositoryPackageList: defeat localization

Set LC_ALL=C, so "sort" produces useful results.

Switch build system from optional package to repositories

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