folders in /boot/beos/, but are real folders, with links to the respective
entries in the /boot/beos/preferences and demos folders. This allows third
party software to place links into the Preferences and Demos entries in the
Deskbar. Fixes ticket #3612.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29745 a95241bf-73f2-0310-859d-f6bbb57e9c96
Two notes by myself:
* I've changed the patch to remove code duplication. This is always preferable.
* GCC4 packages may break, because Haiku does not claim to keep binary
compatibility with itself until after the R1 release. Even then we may not
keep it for GCC4, since Haiku will most likely be GCC2, and there will be a
real GCC4 switch where we will try to make API changes that will be supported
in future releases. So GCC4 packages should be considered very carefully.
In the case of Pe, there may be the benefit of faster launch times, since
most libs will be already loaded (unlike if it's a GCC2 package on a GCC4
Haiku). I am just saying the benefits need to outweight the additional work
to maintain and test these packages.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29744 a95241bf-73f2-0310-859d-f6bbb57e9c96
ported software:
* If the macro B_USE_POSITIVE_POSIX_ERRORS is defined the POSIX error code
constants (ENOMEM, EINTR,...) will have positive values.
* Introduced the macros B_TO_{POSITIVE,NEGATIVE}_ERROR() which do convert a
given error code to a positive/negative value.
* Added static library libposix_error_mapper.a that overrides all POSIX
functions (save the ones I forgot to add :-)) directly meddling with error
codes (having them as parameter or returning them) dealing with the
positive<->negative error code conversions. The functions have hidden
visibility, so they affect only the shared object they are linked into.
* So ideally all one has to do is to build a ported software with
-DB_USE_POSITIVE_POSIX_ERRORS and -lposix_error_mapper and be good with
respect to error code problems.
* Potential issues:
- When mixing ported and Haiku native code, i.e. using Haiku native code in
a ported software or using a ported library in a Haiku native application
care must be taken to convert error codes where the two interface. That's
what the B_TO_{POSITIVE,NEGATIVE}_ERROR() macros are supposed to be used
for.
- A ported static library can obviously not be linked directly against
-lposix_error_mapper. The shared object linking a against the ported static
library has to do that. The previous point applies when that causes mixing
with Haiku native code.
- When dependent ported libraries are used probably all of them should use
the error mapping.
Comments welcome.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29653 a95241bf-73f2-0310-859d-f6bbb57e9c96
which auto-generates dependencies. It was written by Lars Duening for BeOS
and uses libglob, which is also part of make. To re-use libglob and since
make is already part of the Haiku tree, I added mkdepend to the bin tools.
* Added Lars Duening's copyright to AboutSystem.
* Added skeleton makefile and makefile-engine to data/develop.
* Added mkdepend and makefile-engine files to the Development optional package.
It could be argued to move the make bin command there too, from it's current
location in the HaikuImage file. However, make could be useful to always
have available.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29609 a95241bf-73f2-0310-859d-f6bbb57e9c96
--alternative-gcc-output-dir configure option has been specified,
HAIKU_ADD_ALTERNATIVE_GCC_LIBS is set by default. One has to explicitely
unset it in UserBuildConfig to avoid building the alternative gcc libs.
* Adjusted documentation accordingly.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29607 a95241bf-73f2-0310-859d-f6bbb57e9c96
headers in the right places (/boot/common). I made it depend on the Development
package, since without it it wouldn't be useful. It also refuses to install on
a GCC4 based Haiku, since it's intended to help building some popular
BeOS/Haiku software, and there you couldn't link against GCC2 libs I suppose
when you have GCC4 development tools.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29451 a95241bf-73f2-0310-859d-f6bbb57e9c96
- Pe - 2.4.1 built in Haiku gcc2
- BeZillaBrowser -- built in Haiku gcc4
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29420 a95241bf-73f2-0310-859d-f6bbb57e9c96
RecursiveLock in the kernel.
* Several adjustments according to UserlandFS header changes.
* Re-added reiserfs to image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29410 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Check the first argument for "help" as well. If given print a somewhat
helpful text. Consider this my excuse to close ticket #1883. :-)
* Track available and added optional packages and fail, if an optional package
is requested that doesn't exist. Closes ticket #3332.
* Check for duplicate build profile definitions and fail if encountered.
Closes ticket #3333.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29298 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added debugger commands to resolve usb_ids to pipes.
* Adjusted the physical memory allocator to be usable in a slimmed down mode
when running inside the kernel debugger.
* Implemented USB keyboard support for KDL through a kernel debugger add-on.
* Added kgetc() and made use of it where previously individual methods were used
to ensure that reading characters always goes through the kernel debugger
add-ons and the other methods.
This has some preconditions to meet though:
1) The keyboard must be in the boot protocol (currently the case but needs to
be revisited once we have a full usb_hid).
2) The keyboard must be attached to a UHCI root port (i.e. not use EHCI or OHCI,
also not through hubs unless those are USB 1.1).
3) the usb_hid driver has to be opened for this to work. This means that for the
time between initializing USB and when usb_hid is opened by the input_server
there is no keyboard support.
Also note that this has no way of detecting hot-plug, meaning that you can't
re-attach your USB keyboard from the hub to the root port once in KDL.
On the bright side of things, since this is a non-destructive mechanism it is
possible to enter and leave KDL without loosing the USB state.
Tested OK in QEMU, not tested on real hardware yet, will see in a few minutes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29291 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Add attribute_overlay and write_overlay to the image/floppy instead.
* Mount a iso9660 boot volume with both write and attribute overlay for now.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29261 a95241bf-73f2-0310-859d-f6bbb57e9c96
Therefore we switch to building a 2.88 floppy image in that case so it's at
least usable to build a bootable CD.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29211 a95241bf-73f2-0310-859d-f6bbb57e9c96
what we want.
* Remove some more temporary files/directories after the build.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29209 a95241bf-73f2-0310-859d-f6bbb57e9c96
clean yet. Provides a haiku-cd target and creates a bootable image using mkisofs.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29203 a95241bf-73f2-0310-859d-f6bbb57e9c96
* When booting from an iso, mount the boot volume with the overlay layer.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29202 a95241bf-73f2-0310-859d-f6bbb57e9c96
By default it now presents a relatively concise list of USB
devices found on the bus, with an optional -v flag to dump
exhaustive detail. It still also takes an optional device
parameter in case you only want information for a particular
device.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29185 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Also don't install the GCC2 package on a GCC4 based hybrid, as it's again not
usable without proper manual setup.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29160 a95241bf-73f2-0310-859d-f6bbb57e9c96
These all work on pure GCC4 images as well because they do not use any of our
C++ APIs.
* Remove the GCC4 package from hybrid installs though, as it's not usable
without proper setup. Also the trick with rewriting the symlink obviously
doesn't work because symlinks are done way earlier than unzipping the optional
packages when building the image.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29158 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Enable -Werror on GCC4 builds as well (limited to the same selected targets).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29118 a95241bf-73f2-0310-859d-f6bbb57e9c96
and also comes with proper default includes.
* If installing GCC4 as part of a GCC2 based hybrid build, re-setup the gnupro
link that is overwritten by the GCC4 package.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29085 a95241bf-73f2-0310-859d-f6bbb57e9c96
Stephan Aßmus