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.
* Increase general allocation alignment from 4 to 8 byte. That was even
incorrect.
* Use a splay tree instead of a singly linked list to manage the free
chunks. That increases the size of the per-chunk structure to manage
the free chunks, i.e. the of minimally allocatable memory size (from
align(sizeof(void*)) to align(3 * sizeof(void*))), but make finding
and inserting chunks much faster.
Fixes#10063 respectively improves the situation significantly.
* Remove the BUrlRequest class, which was only delegating work to
BUrlProtocol and subclasses
* Rename BUrlProtocol to BUrlRequest, and BUrlRequestHttp to BHttpRequest
* Creating a request is now done through the BUrlProtocolRoster. For
now there is just a static MakeRequest method, this will be completed
when we get to actually allowing add-ons to provide different request
handlers.
This allows cleanup of the API for requests:
* Remove the universal SetOption method with constants, and have
dedicated setters for each protocol option.
* Setters can now have multiple parameters, for example you can give
BHTTPRequest a BDataIO and a known size
* In this case, the BHttpRequest will not use HTTP chunked transfers,
which were always used before and made most servers unhappy (tested and
failed with lighttpd, google accounts and github).
- While building the installed package list, resolve the dependencies
of the OS packages. Flag the resulting list as protected so as
to disallow uninstallation of them in addition to the OS packages.
A hpkg will be created locally, which contains the firmwares. This hpkg will
be copied to system. IIRC, the firmware must live in their respective
subdirectories.
To note, once the approve_license flags are implemented on the end-user
applicacation side, the Intel ipw2100 and Intel ipw2200 could be moved
to a separate package. However (and IIRC) the Broadcom involves using a closed
binary blob, that should not become a pre-made package.
README.iwlwifi-3945-ucode and LICENSE.iwlwifi-3945-ucode were mistakenly marked
as an executable. Was uncertain if iwlwifi-3945-2.ucode should or should not
be marked as an executable and was unchanged.
- A package can potentially be installed in more than one location. As
such, track all of them on PackageInfo (not yet exposed/used).
- Rather than attempting to use location, check the package's flags to
see if it's a system package. If so, disallow deinstallation. Not quite
complete yet though, as we still needs to also resolve the deps of any
system package, and likewise disallow removal of those.
- If a package was installed, but didn't have a corresponding remote
repository package, it would have been missed in the list. Detect these
and create a special local depot object to house them, so they also make
their way into the visible package list.
Thanks to diver for reporting the discrepancy.
- Since the package list is built lazily in the background, the list of
depots won't actually be available immediately at construction time.
Defer building the menu for both that and the categority list until the
model has actually been populated.
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.
Should already have been done back when the semantics for the
B_COMMON_*DIRECTORY constants was changed.
Currently old and new version behave the same. So this is just a
contingency measure ATM.
* This does intentionally break source compatibility, so that a review
of concerned code is forced.
* Binary compatibility should be maintained in most cases. The values
of the constants for the writable directories are now used for the
writable system directories. The values for the non-writable
directories are mapped to "/boot/system/data/empty/...", an empty or
non-existent directory, so that they will simply be skipped in search
paths. Only code that explicitly expects to find something in a
B_COMMON_* directory, will fail.
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).
