* Added command management, an interactive input loop, and a few basic
commands.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20876 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Moved all inclusions of system headers into a new
system_dependencies.h header, which conditionally either includes
these or the FS shell headers.
- Fixed compiler warnings related to printf-like functions (int32 is
int, not long on non-BeOS platforms).
* Build a new bfs_shell. Compiles and links, but does nothing ATM.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20860 a95241bf-73f2-0310-859d-f6bbb57e9c96
Doesn't do anything ATM, but already provides the required system
interface (VFS, caches, POSIX functions).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20859 a95241bf-73f2-0310-859d-f6bbb57e9c96
section of an ELF object. Probably won't build under BeOS yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20080 a95241bf-73f2-0310-859d-f6bbb57e9c96
Tested with VMware Player 1.0.3 on linux and works.
Can also be used to create a haiku.vmdk file from an existing haiku.image file:
rm haiku.vmdk
generated/objects/linux/x86/release/tools/vmdkheader/vmdkheader -h 64k -i100M haiku.vmdk
cat generated/haiku.image >>haiku.vmdk
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19980 a95241bf-73f2-0310-859d-f6bbb57e9c96
It's hopefully now used everywhere instead of B_RAW_TYPE where appropriate.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19219 a95241bf-73f2-0310-859d-f6bbb57e9c96
platforms. Instead, it uses the (extended) Linux compatibility layer classes, so that
it supports setting vector icons as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@19203 a95241bf-73f2-0310-859d-f6bbb57e9c96
style fixes
HeaderSampler.pl now outputs the good methodsynopsis content to copy/paste
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18853 a95241bf-73f2-0310-859d-f6bbb57e9c96
It includes a change to xsltproc to accept catalog paths on the command line.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@18763 a95241bf-73f2-0310-859d-f6bbb57e9c96
However, an eventual existing system version info is dropped - support for this
(also on the compilation side) should be implemented as well some day.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17824 a95241bf-73f2-0310-859d-f6bbb57e9c96
stupid bug that will generally remove the last byte of any attribute.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@17771 a95241bf-73f2-0310-859d-f6bbb57e9c96
* "rc" now accepts stdin as input file when "-" is used as a file name.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16225 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added --dry-run option for paranoid ones like me.
* Added support for making partition devices bootable under Linux (x86, BIOS).
When specifying respective values for HAIKU_IMAGE_{DIR,NAME} ("/dev" and
e.g. "sda7") a "jam haiku-image" will now replace the contents of your
favorite partition with a fresh Haiku installation. BE WARNED: This is nothing
for the faint of heart and I don't guarantee that my implementation is bug-free
and won't mangle the contents of your hard disk even if you use it correctly.
That being said, note that you'll probably have to run the "jam haiku-image"
as root, if you want to access the partition devices, which is a bit annoying.
Furthermore, if the build_haiku_image script fails for any reason, jam tends
to remove the image file, which in this case would be a partition device node.
The mknod command will be your friend in this case.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@16148 a95241bf-73f2-0310-859d-f6bbb57e9c96
when receiving a HELLO request. Thus it doesn't need to be restarted
when the image had been rebuilt. That was a bit annoying...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15735 a95241bf-73f2-0310-859d-f6bbb57e9c96
to make the build system happy for now. We'll see later what we
have to do.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15400 a95241bf-73f2-0310-859d-f6bbb57e9c96
the sizes and alignments of syscall parameters. It no longer
generates and compiles functions with the same signature as the
syscalls. This simply doesn't generally work for cross-compilation.
Instead we provide a bit of architecture-specific code that knows
how things work for the target architecture.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15196 a95241bf-73f2-0310-859d-f6bbb57e9c96
categories:
* Missing includes (like <stdlib.h> and <string.h>).
* Linking against $(TARGET_LIBSTDC++) instead of libstdc++.r4.so.
* Local variables shadowing parameters.
* Default parameters in function definitions (as opposed to function
declarations).
* All C++ stuff (nothrow, map, set, vector, min, max,...) must be imported
explicitly from the std:: namespace now.
* "new (sometype)[...]" must read "new sometype[...]", even if sometype is
something like "const char *".
* __FUNCTION__ is no longer a string literal (but a string expression), i.e.
'printf(__FUNCTION__ ": ...\n")' is invalid code.
* A type cast results in a non-lvalue. E.g. "(char *)buffer += bytes"
is an invalid expression.
* "friend class SomeClass" only works when SomeClass is known before.
Otherwise the an inner class with that name is considered as friend.
gcc 4 is much pickier about scopes.
* gcc 4 is generally stricter with respect to type conversions in C.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14878 a95241bf-73f2-0310-859d-f6bbb57e9c96
a few whether they actually work.
New pseudo target "unittests", which builds all unit tests for the currently
set TARGET_PLATFORM. They are placed in generated/tests/<platform>/unittests.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14791 a95241bf-73f2-0310-859d-f6bbb57e9c96
