This is important when setting up the TARGET_LIB* constants later, in case
the target platform is not "haiku". (i.e. libbe_test).
* Added TODO about HOST_GCC_BASE_FLAGS being wrong for GCC4. I couldn't find
the proper fix, but it is important whan compiling libbe_test on Haiku.
I worked around this by having the constant defined correctly for the
problematic file. See the TODO comment.
* Small cleanups.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@33246 a95241bf-73f2-0310-859d-f6bbb57e9c96
is obviously already configured not to use patented code.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32577 a95241bf-73f2-0310-859d-f6bbb57e9c96
make it work, one would need to use versioning for all libbe symbols. This is
worth an 8k price per file that links against libbe.so, so I didn't want to
commit this as is. An alternative to this solution would be to write a
separate application that is responsible for the app_server's window. Comments
welcome.
* Removed BeOS compatbility of the libbe_test stuff.
* Renamed the libbe_test targets from *haiku* to *test*, ie. libbe_haiku.so is
now called libbe_test.so, haiku_registrar is now test_registrar, etc.
* This also removes BeOS compatibility from tracker/FSUtils.cpp (all BeOS
compatibility should be removed, but I don't want to make Alexandre more work
in his branch, and it's not urgent at all).
* Replaced the former "run" scripts for the test environment with a single
run script (see updated NOTES file).
* Removed the libbe_test target from some applications - this was only to help
developing them under BeOS, and is thus no longer necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32521 a95241bf-73f2-0310-859d-f6bbb57e9c96
anymore with the small size, and it didn't fix the problem I originally hoped
it would.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32495 a95241bf-73f2-0310-859d-f6bbb57e9c96
- consolidate board specific definitions into build/jam/board/*/BoardSetup to avoid duplicating address values everywhere,
- add various addresses, boot script, custom C/C++ flags and SD card definition,
- not sure BoardSetup is included at the best place though,
- replaced board-specific ldscript with passing the loader address directly to LD from BoardSetup,
- added haiku.mmc target which generates an mmc/SD card image with a FAT partition with the files needed to boot for the board, should later be integrated with haiku.image with the BFS partition offset passed to bfs_shell, requires apt:sfdisk,mtools on GNU/Linux,
- added some more rules, one to build a script for the SD image,
- fake a NetBSD loader for now, U-Boot doesn't know haiku, and we'll need a way to pass the tgz image and RAM size, we'll either use standlone way (usual C argv[]) or the NetBSD args,
- style fixes,
- 80 cols, /me pets Ingo.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32284 a95241bf-73f2-0310-859d-f6bbb57e9c96
on it. With the other changes already made, we can now use a 1440k boot image
for x86 as well, again.
* If you build a CD, you'll have to take extra care to see whether it still fits
on the floppy or not - space is really tight already.
* Made USB support optional for the CD-ROM. It's turned on, though, since we do
want to support USB-CD-ROMs by default; this is just something you can use
once in case we need to enlarge the boot floppy to 2880k again.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32282 a95241bf-73f2-0310-859d-f6bbb57e9c96
Since we don't support Flattened Device Trees yet (and they don't solve all the issues), we need a place to hole board-specific config, which are different even though we use U-Boot on ARM. Things like cpu & mmu type...
U-Boot doesn't really help us there anyway, it only passes a few board infos (RAM banks & the bill), and optionally other stuff if we fake a linux kernel or netbsd loader, but still not enough. FDT support isn't available for ARM in U-Boot yet either. So for now, and likely for stuff we can't get from FDT, we'll put board-specific config there.
Unlike desktop machines were we want a single kernel per arch, we'd rather have the kernel built for a single board without having to handle detecting mmu type at boot and switching calls like I did on m68k.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@32137 a95241bf-73f2-0310-859d-f6bbb57e9c96
Now that's done like building the network boot archive, which gives us a lot
more flexibility for defining its contents.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30850 a95241bf-73f2-0310-859d-f6bbb57e9c96
symbols recently introduced. Until init_term_dyn.o is linked into kernel
add-ons, too, we link with haiku_version_glue.o, so we have those symbols
in kernel add-ons as well.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30818 a95241bf-73f2-0310-859d-f6bbb57e9c96
sets the HAIKU_YASM build variable, which will be checked in BuildSetup.
Re-running configure or adding the variable manually to
generated/build/BuildConfig is required.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@30145 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Made the TimeZoneView less error prone, and also actually use Haiku code (the
previous check didn't work since it used #if, not #ifdef).
* Also took the liberty to rename our boot loader to haiku_loader, since I had
to update the nasm binary anyway. Updated the assembly sources to nasm 2.0.
* I haven't found where the synth location in the MIDI code is specified,
though.
* Also, NetBootArchive, and FloppyBootImage haven't been updated yet. Will do
so next.
* Some optional packages still put their license to beos/etc/licenses. I didn't
update them yet, as we'll probably do so anyway at some point. Also, I think
we might want to introduce a common/data/licenses instead for those.
* If you encounter any problems, please tell!
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@29876 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
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
* 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
the main() signature are not applied and do not generate errors when violated.
Our bootloader has a non-standard main() signature for example, which is of
course fine.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28983 a95241bf-73f2-0310-859d-f6bbb57e9c96
the wrong Link actions were used (always the no-attributes-support ones
which remove the target first), for instance.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@28304 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
HAIKU[_KERNEL]_WARNING_CCFLAGS.
* Added -Werror for various parts of the source tree for the gcc 2
build. Feel encouraged to add more.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27842 a95241bf-73f2-0310-859d-f6bbb57e9c96
- For simplicity we'll force using only insn common to 020 to 060, mostly to avoid unimplemented floating point ops in the kernel.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26647 a95241bf-73f2-0310-859d-f6bbb57e9c96
* add cygwin specific options.
* Cygwin cannot handle -fPIC option and throws warnings, thus we only use it on non windows platforms for the host tools.
* Windows uses PATH instead of LD_LIBRARY_PATH, so before calling a host tool this environment variable needs to be expanded... Brilliant...
* Using jam on Windows is kind of complicated, as the cygwin included gcc creates executables with a .exe extension. When jam parses dependencies for being up to date it ignores this extension again and tries to rebuild the executables again and again. This hack removes the extension after successful linking. Though jam has a SUFEXE variable for cygwin builds, we cannot use this one directly as crosscompiled targets do not have an extension, it is complicated to use the same jam for both platforms. A more clean attempt would be to check for the extension on each host target depending on the platform. This should be fixed later on.
* Btw. Say hello to Haiku compiling successfully on Windows :) with one patch to be discussed for jam...
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@26590 a95241bf-73f2-0310-859d-f6bbb57e9c96
