* 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.
* before adding a child to a parent entry, we need to check if the
parent already contains that child, as otherwise duplicate children
with identical names would be added, which in turn messes up the
handling of the entries that are to be extracted
* 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.).
<stddef.h> is just fine and it doesn't break the use of libroot headers
when compiling something with -nostdinc++ (in C++ mode).
Not particularly important, but this gets compiling the libio C++ stuff
when building a native gcc a bit further. It still fails, since our
<printf.h> header is actually not usable (it includes <features.h>,
which is not available in Haiku) -- something we should fix eventually.
* Add a VMArea* version of AddArea().
* AddAreaCacheAndLock(): Use the new AddArea() version. This not only
saves the ID hash table lookup, but also fixes a race condition with
delete_area(). delete_area() removes the area from the hash before
removing it from its cache, so iterating through the cache's areas
can turn up an area that no longer is in the hash. In that case we
would fail immediately. The new AddArea() won't fail in this
situation, though.
Fixes#9686: vm_copy_area() could fail for the "commpage" area. That's
an area all teams share, so any team terminating while another one was
fork()ing could trigger it.
We the meta data area couldn't be allocated in any of the supported
(reattachable) places, just use a static allocation. The tracing feature
wouldn't be available at all in such a case.
... more aggressively than before:
* Only use modifiers().
* Before forwarding any relevant event to the active state, first check
whether the modifiers have changed.
While the issues should really be fixed where they originate (app
server?), this hopefully fixes all situations where the hyperlink mode
gets stuck.
- MarkerView: If the view was resized, and the newly revealed region was
after the last source line, it wouldn't be redrawn properly.
- TextView: Reset low color for painting the region after the
source. Otherwise, if either the instruction pointer or a breakpoint
were at the last line of the current source, the empty space after would
be filled in that color rather than the background color.
- When switching between breaking on all images vs a custom list, rather
than enabling/disabling the controls individually, which wasn't
necessarily obvious from a visibility standpoint, simply show/hide the
entire group of controls as needed.
- Update state of add/remove buttons properly.
- Sanitize input for leading/trailing whitespace.
* fill it with HT MSI mapping capability information.
* enable/disable mapping on the device accordingly in enable_msi(),
disable_msi(), enable_msix(), disable_msix().
* untested. The mapping could instead be enabled/disabled on the HT PCI bus,
aka the parent device of the device passed to enable_msi/disable_msix().
* untested.
* as it's possible to have several HyperTransport capability blocks, the offset parameter
is used as the start pointer for the search in case it's non zero.
