This file was apparenly based off the BeOS one (as is evidenced
by the "Be Incorporated" copyright ... which is problematic.)
Now it's directly based off of the non-build one.
* Put it in the BSupportKit namespace, following the style introduced
with the package kit for now.
* The BSupportKit::BJob class no longer knows about the package kit's
Context class. However, the BPackageKit::BJob class does.
* Due to the namespace juggling, a lot of files had to be touched.
* The JobQueue class remains private.
* Due to the way Haiku is built on itself, you cannot build this change
under Haiku with an older release.
* This avoids polluting the Haiku headers with host issues,
as pointed out by Axel.
* Should also resolve build issues for various versions of
host compilers that were introduced in previous commits.
* Previously PE binaries would trigger the "incorrectly
executable" dialog. Now we get a special message for
B_LEGACY_EXECUTABLE and B_UNKNOWN_EXECUTABLE
* Legacy at the moment is a R3 x86 PE binary. This could
be extended to gcc2 binaries someday far, far, down the
road though
* The check for legacy is based on a PE flag I see
set on every R3 binary (that isn't set on dos ones)
* Unknown is something we know *is* an executable, but
can't do anything with (such as an MSDOS or Windows
application)
* No performance drops as we do the PE scan last
* Tested on x86 and x86_gcc2
* libbe_build: Where possible we directly use the actual Haiku headers and
sources, now. In the headers/build headers we just include the respective
Haiku headers as needed. That still allows overrides where necessary. The
intention is to make it easier to keep the build stuff in sync.
* Fixed a few printf() format and signed/unsigned comparison warnings.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42179 a95241bf-73f2-0310-859d-f6bbb57e9c96
* the libbe_build version of BString was broken, at least with respect
to LockBuffer() on an empty string - replaced the implementation and
header with our current version (keeping the type-related changes
required by the build-version)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@40526 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Added macro __HAIKU_ARCH_BITS specifying the architecture bitness (32/64)
(might be more convenient to use than __HAIKU_ARCH_{32,64}_BIT).
- Added macros __HAIKU_ARCH_PHYSICAL_BITS, __HAIKU_ARCH_PHYSICAL_{32,64}_BIT,
and the types __haiku_phys_[s]addr_t. The intention is to use separate
macros and types for virtual and physical addresses, since for some
architectures (e.g. x86 with PAE) those actually differ.
* sys/types.h, BeBuild.h, SupportDefs.h:
- Added types phys_[s]addr_t and respective printf() format macros.
- Added public macros B_HAIKU_BITS, B_HAIKU_PHYSICAL_BITS,
B_HAIKU_PHYSICAL_{32,64}_BIT.
Might break the build under older Haiku installations. Will test next.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36926 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added FSSH_[S]SIZE_MAX to headers/private/fs_shell/fssh_types.h.
* Fixed various 64 bit compiler warnings. Nothing too serious, though.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34241 a95241bf-73f2-0310-859d-f6bbb57e9c96
some unneeded ones, which still had the be copyright. Also removed BufferIO
from the build and deleted the implementation, since it wasn't used.
There are still some more... +alphabranch
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32829 a95241bf-73f2-0310-859d-f6bbb57e9c96
We now keep track of a lower bound as to when the list should scale
itself back down. When increasing the list size, we double the current,
with the lower bound set to 1/4 of the current size, not allowing it to
go any smaller than the block size. These combined allow us to do very
cheap tests to see if an operation requires a resize at all, and minimize
how often the list actually needs to be resized, since the difference in upper
and lower bounds prevents bouncing back and forth between a size in the case
of adding/removing an item while close to a boundary. All in all this should
make BList noticably more scalable when doing large numbers of add/remove
operations.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25946 a95241bf-73f2-0310-859d-f6bbb57e9c96
version. This gets rid of the _IMPEXP* definitions so it should not cause
any trouble.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24184 a95241bf-73f2-0310-859d-f6bbb57e9c96
headers/os version and removed the now duplicate icon type constant
definitions from several sources.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24106 a95241bf-73f2-0310-859d-f6bbb57e9c96