* 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
* Remove 4.2 sourcecode
* ICU is now an optional package (mandatory)
* Adjust the namespaces and libraries names where needed
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@37498 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
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
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
It's supposed to be filled with the entry name of the directory and not as in
all the other cases used as a leaf name to be appended to the dir. This would
lead to some errors with operations based on directory fds in the build libroot
and build libbe and in the end make generate_attribute_stores fail on platforms
that don't have an 0 initialized stack (since the supplied name buffer would
contain garbage later attached to the directory path).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29227 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Renamed fs_attr_xattr.cpp to libroot/fs_attr_untyped.cpp.
* Pulled the xattr specifics into a separate fs_attr_xattr.h.
* Added fs_attr_extattr.h, interfacing with FreeBSD's extattr support.
Totally untested yet. Might not even compile.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27350 a95241bf-73f2-0310-859d-f6bbb57e9c96
* rc uses a global instance of BResources. On destruction it calls Unset() of the BFile member fFile. BNode::Unset then calls close_fd(), which parses the static global DescriptorMap to actually close the descriptor. However on Cygwin the DescriptorMap has been destroyed already for some reason, thus accessing it is invalid. The "fix" is to put the map on the heap and delete it as soon as it gets empty. This way the global BResources instance can be freed without a crash.
* If someone likes to review, feel free to, it didn't cause any issues here
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26585 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
patch by Vasilis Kaoutsis. I may have cleaned up the file a bit, too.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25602 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Export a fake _get_port_message_info_etc() for KMessage in libbe_haiku.so
This fixes the build of the app_server test environment.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25202 a95241bf-73f2-0310-859d-f6bbb57e9c96
Haiku code, they work around buggy BeOS code not present on Haiku.
* If this code turns out to be problematic under Haiku (Bruno, did your changes
make any difference at all?), then please fix the problems in the Storage
Kit, don't enable work-arounds for BeOS.
* Simplified the macro check as suggested by Ingo.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24790 a95241bf-73f2-0310-859d-f6bbb57e9c96
if these changes are correct byt they seem to make sense. Ingo?
- Haiku uses the same code that BeOS/Dano/Zeta uses for mime related stuff
during the build process. Added checking for HAIKU_HOST_PLATFORM_HAIKU where
relevant.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24782 a95241bf-73f2-0310-859d-f6bbb57e9c96
