Global and user settings files can be declared. For global ones an
update policy can be specified. If not specified, the settings file is
not included in the package, but created by the program (or user) later.
If an update type is specified, it defines what to do with the settings
file when updating the package to a newer version.
User settings files are never included in the package; they are always
created by the program or the user. If the package contains a template/
default settings file, it can be declared, but for informative purposes
only.
Instead of handling compression for individual file/attribute data we
do now compress the whole heap where they are stored. This
significantly improves compression ratios. We still divide the
uncompressed data into 64 KiB chunks and use a chunk offset array for
the compressed chunks to allow for quick random access without too much
overhead. The tradeoff is a limited possible compression ratio -- i.e.
we won't be as good as tar.gz (though surprisingly with my test
archives we did better than zip).
The other package file sections (package attributes and TOC) are no
longer compressed individually. Their uncompressed data are simply
pushed onto the heap where the usual compression strategy applies. To
simplify things the repository format has been changed in the same
manner although it doesn't otherwise use the heap, since it only stores
meta data.
Due to the data compression having been exposed in public and private
API, this change touches a lot of package kit using code, including
packagefs and the boot loader packagefs support. The latter two haven't
been tested yet. Moreover packagefs needs a new kind of cache so we
avoid re-reading the same heap chunk for two different data items it
contains.
It uses sub-namespace BPackage::BHPKG::V1. Unlike the one for the
current format version, the V1 version of BPackageInfoContentHandler
lives in BHPKG(::V1) sub-namespace and is private.
This means the build tools will no longer be built against the host
platform's libbe, which avoids compatibility problems -- e.g. an
older Haiku host libbe may not have certain features the build tools
require -- and also makes the build behave more similiar on Haiku and
other platforms. The host libroot dependency still remains and is not
easy to get rid of.
Also remove some bits of BeOS/Dano/Zeta build support.
* Pull out base class MimeEntryProcessor out of AppMetaMimeCreator.
* Pull class MimeInfoUpdater out of UpdateMimeInfoThread and derive it
from MimeEntryProcessor.
* MimeInfoUpdater: Instead of BMimeType::GuessMimeType(), use
Database::GuessMimeType() directly.
* This pulls in some more stuff, like libicon and agg which are also
included in libbe_build, now.
* Update a few libbe_build classes and headers needed to get things
building.
* This likely breaks the <build>mimeset build on Haiku.
* daemon: Handle new request B_MESSAGE_COMMIT_TRANSACTION. It activates
and deactivates given sets of packages. The new packages must be
placed in a directory in the administrative directory. The daemon
moves them to the packages directory and the deactivated packages to
a subdirectory it creates. It also save the old activation state
there.
* Add private BActivationTransaction, describing an activation change
transaction.
* BDaemonClient: Add CommitTransaction(), which sends a given
BActivationTransaction as a B_MESSAGE_COMMIT_TRANSACTION request to
the daemon.
Completely untested yet.
* fs_darwin.c => fs_darwin.cpp
* fs_freebsd.c => fs_freebsd.cpp
* use bool instead of int again in fs_darwin.cpp (C => C++)
* declare loop varibles inline again in fs_freebsd.cpp (C => C++)
* 2 newlines between top header gaurd and first #include
* 2 newlines after last #include
* freebsd/endian.h and freebsd/regex.h convert \r\n to just \n
* remove some leading tabs in fs_freebsd.cpp
* add newlines after single line if statement in fs_freebsd.cpp
* 80-char limit fixes in fs_freebsd.cpp
This completes the final 1/3 of #8857. Changes again by nielx with
style fixes by me.
The one part that I couldn't figure out, and maybe Ingo can chime
in here. If headers/build/host/darwin/sys/stat.h is surrounded in
extern "C" {
}
guards then I get a link error complaining that the functions defined
here are duplicate symbols, once in fs.o and once in function_remapper.o.
For example:
ld: duplicate symbol _futimens in generated/objects/darwin/x86_64/release/build/libroot/libroot_build_function_remapper.a(function_remapper.o) and generated/objects/darwin/x86_64/release/build/libroot/libroot_build.a(fs.o) for architecture x86_64
I'm not sure why that is.
Apparently I should have done a complete rebuild after moving
directories.h from headers/private/libroot to .../system, since a lot of
stuff didn't build anymore.
The implementation is temporary. Currently it reads through the packages
in the respective packages directory and checks against the package
links. Once package activation is tracked explicitly we'll use the
activation file/directory.
A BPackageContentHandler subclass that initializes a BPackageInfo from
the read package attributes. Pulled out of RepositoryWriterImpl's
PackageContentHandler.
This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.
Apparently I should have done a complete rebuild after moving
directories.h from headers/private/libroot to .../system, since a lot of
stuff didn't build anymore.
The implementation is temporary. Currently it reads through the packages
in the respective packages directory and checks against the package
links. Once package activation is tracked explicitly we'll use the
activation file/directory.
A BPackageContentHandler subclass that initializes a BPackageInfo from
the read package attributes. Pulled out of RepositoryWriterImpl's
PackageContentHandler.
This makes opening symlinks work universally in the build system tools.
Two mechanisms have been implemented, both of which don't always work.
The first is remapping via preprocessor macros. This fails where equally
named methods are used (e.g. STL fstream::open()). The other is using
hidden functions in the new libroot_build_function_remapper.a that is
linked into everything that is linked against libroot_build.so. This one
fails for functions that are defined inline in headers (Linux/glibc does
that). Together they seem to cover our build system needs ATM.
* 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
Cygwin and Solaris rely on Haiku supplying a glibc-compatible regex.h header.
Before r38031, Solaris was able to reuse cygwin/regex.h successfully. Import
the latest stable 2.11 posix/regex.h to avoid local trickery and to silence
some RE_* errors.
It is very likely necessary to update cygwin/regex.h as well, but I don't have
a test setup to verify.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@38096 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 a few header files in headers/posix/arch that'll allow for an x86_64
haiku target to be compiled. fenv.h is src/lib/msun/amd64/fenv.h from
freebsd.
* configure: Added support for x86_64 arch when running
build_cross_tools_gcc4.
* config[_build]/HaikuConfig.h, BuildSetup: Added x86_64 recognition.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36794 a95241bf-73f2-0310-859d-f6bbb57e9c96
of BKeymap was not compatible with IsDeadKey() of the other Keymap
incarnations.
* Now, I've renamed IsDeadKey() to DeadKey(), and introduced a new
ActiveDeadKey() method that works like the other former IsDeadKey().
* This fixes the dead key problems my earlier BKeymap work introduced.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36400 a95241bf-73f2-0310-859d-f6bbb57e9c96
* keymap and <build>keymap are now using the BKeymap class as a base as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@36368 a95241bf-73f2-0310-859d-f6bbb57e9c96
conditionally define some of the new stuff there. That fixes the build under
a r34172 Haiku, though it also causes some problems that needed working around.
Haven't tested under newer Haiku revisions yet. Will do tomorrow.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34267 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
That's just leading to problems.
* Fixed various 64 bit warnings when building libbe_build.so. One of the more
serious issues, that might bite us, is that 64 bit Linux defines dev_t to
unsigned long, while Haiku code assumes that it is signed and 32 bit. We'll
see...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34227 a95241bf-73f2-0310-859d-f6bbb57e9c96
* BuildSetup: Set jam variable HOST_PLATFORM_IS_64_BIT and add host define
HAIKU_HOST_PLATFORM_64_BIT if the host platform is 64 bit. Removed the
check from BeOSBuildCompatibility.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@34211 a95241bf-73f2-0310-859d-f6bbb57e9c96
work to do, but it's about time to give this code more exposure.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33176 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
* Implemented BGradient, BGradientLinear, BGradientRadial,
BGradientDiamond, BGradientConic and BGradientRadialFocus
new Interface Kit classes.
* Implemented all the (AGG-based) backend necessary in
the app_server to render gradients (Painter, DrawingEngine)
* app_server/View can convert a BGradient layout to screen
coordinates.
* Added BGradient methods of the Fill* methods in BView.
* Implemented a test app and added it to the image as a
demo.
* Adopted Icon-O-Matic and libs/icon in order to avoid
clashing with the new BGradient class. Re-use some
parts where possible.
Awesome work, Artur! Thanks a lot. Now a more modern
looking GUI has just become much easier to implement! :-)
TODO:
* Remove the need to have gradient type twice in the
app_server protocol.
* Refactor some parts of the patch to remove duplicated
code (Painter, DrawingEngine).
* Adopt the BPicture protocol to know about BGradients.
* Review some parts of the BArchivable implementation.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28109 a95241bf-73f2-0310-859d-f6bbb57e9c96
* added opengl to build be api headers
* define USES_BE_API for gen_matypes
this should fix the build for Linux which don't provide GL headers :)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28050 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When drawing BBitmaps with scaling in the app_server, use a bilinear
filter when a bitmap has this flag set. (Hope nobody objects, otherwise
I can revert or improve this. Performance can certainly be improved, since
the AGG implementation is too generic. But that goes for the nearest
neighbor implementation as well.)
* Flags are uint32, fix app_server side code to declare them correctly. Use
appropriate link methods in BBitmap and ServerApp.
* Enable the BeOS compatibility mode for B_RGB32 (works just like B_RGBA32
in B_OP_ALPHA mode).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26649 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cygwin does not have regex support, so we use the one we already have in our glibc.
* Keymap.h has a automatic forward declaration of re_registers, which causes a compile break on Cygwin, but not on other platforms. So add a include for regex.h in the header and remove it in the source file.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26587 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Cygwin needs some additional defines compared to other platforms
* Additionally stpcpy and strcasestr are unknown on Cygwin. Thus we need to use the one from our posix library.
* ECANCELED is not defined on Cygwin, so only add error in case it is.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26584 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
builds on Linux with gcc 2 and 4, but the images do even run. :-) Not
tested on BeOS.
* Removed stddef.h and stdarg.h. They are provided by the compiler.
* Adjusted size_t.h, wchar_t.h, and wchar.h accordingly.
* Made stdio.h avoid gcc 2.95.3's fixincludes hack stdio_va_list
* Added gcc 2.95.3 headers to the repository. They are used instead of
the headers of the gcc 2.95.3's we use to compile Haiku with. Should
avoid build problems with the BeOS native compiler.
For sake of personal recreation you can rebuild the cross gcc 2.95.3,
but the only thing that changed is its header directory
(lib/gcc-lib/.../include), which isn't used anymore. Replacing it with
headers/build/gcc-2.95.3 should have the same effect as rebuilding, BTW.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24413 a95241bf-73f2-0310-859d-f6bbb57e9c96
of the resolved ToDo, but could probably be made more efficient. Instead of
transfering the area, the area is cloned into the target teams' address space
and the original is deleted. This generates a new area_id for the transfered
area (as suggested by the ToDo). Updated syscall prototypes according to the
status_t to area_id return type change.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24320 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
* added HaikuBuildCompatibility.h to the src/build/* files that are built as
part of the tools we need to build Haiku.
* Changed HaikuBuildCompatibility.h so that it does not define the things
that are already in the build headers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24147 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
HaikuBuildCompatibility.h; this fixes building agp_gart and the intel
extreme driver for BeOS.
* Added sockaddr_storage to HaikuBuildCompatibility.h.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23823 a95241bf-73f2-0310-859d-f6bbb57e9c96
Replaced IDE_ADAPTER_IS_PRIMARY by IDE_ADAPTER_CHANNEL_INDEX to support more than 2 bus master channels,
and made ide_adapter aware of 3rd and 4th channel when calculating bus master dma address.
Fixed bus master DMA support in legacy_sata driver for tertiary and quaternary channel, channel 3 and 4
were using the DMA engine of primary and secondary channels (that might have destroyed your data).
Use PCI_address_io_mask instead of ~PCI_address_space (no functional change).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@23207 a95241bf-73f2-0310-859d-f6bbb57e9c96
(yes I still use that), but there are more problems, regarding
for example BPrivateScreen definition and the disk device API stuff,
I am kind of clueless regarding those. :-(
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@22623 a95241bf-73f2-0310-859d-f6bbb57e9c96
BDirectory without declaring it first. Since that's an actual bug, I made the
changes in the Haiku headers, and copied them back to the build headers.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21562 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also ported over the new MessageAdapter class
* Removed old BMessage implementation prototypes that apparently were left in the private folder
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21515 a95241bf-73f2-0310-859d-f6bbb57e9c96
building on Mac OS X (Darwin). A problem with makebootable remains.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@21165 a95241bf-73f2-0310-859d-f6bbb57e9c96
