I didn't manage to define this in the Jamfile (anyone, feel free to fix this)
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12393 a95241bf-73f2-0310-859d-f6bbb57e9c96
added rules to produce xml from man pages
still to be sharpened :
xml files could only be objects but they are located in distro ATM
users don't read xml AFAIK, so final documentation is to be reworked
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12392 a95241bf-73f2-0310-859d-f6bbb57e9c96
called kernel_${arch} like on disk. A "jam kernel" will still work, though.
Also updated all those Jamfiles I forgot to update before.
Since makehdimage now runs through (and even builds a working image), I guess
most of the consequences of the "kernel/core" -> "system/kernel" rename task
are solved.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12364 a95241bf-73f2-0310-859d-f6bbb57e9c96
- SupportDefs.h only includes stdbool.h if included from C
- stdbool.h for C++ now includes a macro for "bool" as defined by that header
- stdbool.h does nothing if __bool_true_false_are_defined is already defined
- stdbool.h no longer defines a _Bool enum, but defines _Bool as unsigned char, as
previously done by SupportDefs.h (the previous version changed the size).
- The gensyscalls Jamfile now preprocesses its headers in C++ mode so that "bool"
stays "bool", and doesn't become _Bool.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@12042 a95241bf-73f2-0310-859d-f6bbb57e9c96
(Daniel Furrer).
* The strace interface for the generated file changed.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11495 a95241bf-73f2-0310-859d-f6bbb57e9c96
pointers and overall parameters size for the kernel and some more
sophisticated code for strace.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@11339 a95241bf-73f2-0310-859d-f6bbb57e9c96
experienced this problem, but others have). Original changes by Axel,
though edited quite a bit by myself.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@10337 a95241bf-73f2-0310-859d-f6bbb57e9c96
To use this feature run StatCacheServer somewhere in the background.
The first run of jam will be slower, but subsequent ones will usually
benefit. Only little, if the BeOS FS cache is able to hold the data,
but as soon as the number of files and directories jam has to inspect
hits the limit at which the cache drops data needed for the next run,
the performance difference will be very noticeable.
E.g. the time for a "jam -n > /dev/null" in the root of a partially built
tree on my machine dropped from >1 min without the server to 13 secs
with it (not in the first run, of course).
Although tested quite a bit, I would still consider the feature
experimental.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9671 a95241bf-73f2-0310-859d-f6bbb57e9c96
A bug in the function reading the cache file caused everything after a
file beginning with an empty or comment line to be ignored. Since our
Jamrules begins with a comment and only after reading Jamrules the cache
starts to work anyway, it indeed had no effect at all.
Added some error output in case reading the cache file failed, so that
this can't happen unnoticed again.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@9659 a95241bf-73f2-0310-859d-f6bbb57e9c96
boring syscall stuff. It has two phases now: The first one
(gensyscallinfos) parses syscalls.h and generates a source file containing
all the required information. This file is compiled and linked to
gensyscalls, which generates the actual output files.
Added to the build.
git-svn-id: file:///srv/svn/repos/haiku/trunk/current@8697 a95241bf-73f2-0310-859d-f6bbb57e9c96
Jérôme Duval