* 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
Ingo Weinhold