Following recent changes to use libroot_build on Haiku also, it is now
actually impossible to build Haiku components on non-Haiku platforms
(BeOS R5, Dan0, BONE, Zeta), so we can remove any logic related to this.
This is only the first part; still to be removed are:
* SetSubDirSupportedPlatformsBeOSCompatible
* HOST_PLATFORM_BEOS_COMPATIBLE
* TARGET_PLATFORM_BEOS_COMPATIBLE
provided in the gcc_syslibs_devel build feature for building Haiku.
* Simplify declaration of c++ and gcc headers for the legacy compiler -
in the end we always use the ones living by our source tree anyway.
* Fix a couple of missing local declarations for jam variables, which
were necessary to avoid a build problem with strace. There are
probably more bugs like these hiding in our build system files, but
I'm saving the fix for those to the next commit.
* Add new gcc packages to the HaikuPorts (x86*-)repositories.
* The main build rules now cause their targets to depend on the
platform such that global per-platform intializations can be
set up by making the platform pseudo target depend on the
target returned by the initialization rule.
HAIKU_* variables are copied to TARGET_*, making it possible to also
build for other targets (libbe_build, or BeOS R5 when we still allowed
that).
Thanks to Ingo for explaining how this is meant to work.
* ArchitectureRules define a variable named HAIKU_ASFLAGS, so other
Jamfiles can append to it.
* But, TARGET_ASFLAGS was used instead in the single place where we
tried to make use of this (the verdex BoardSetup), and in the As rule
* Moreover, the As rule used $(architecture) instead of
$(TARGET_PACKAGING_ARCH) (I suspect a bogus copypaste?). So, it never
actually made use of the flags
With this working, add the proper flags to the BeagleBoard BoardSetup,
so we implement atomic operations the ARMv7 way (no need to syscall).
This helps with compiling, as the As and Cc/Cpp rules now agree on the
defines and the atomic implementation to use.
The introduction of secondary arch support for kernel files disabled
-Werror for all kernel files, since the -Werror flags were moved from
{CC,C++}FLAGS to TARGET_WARNING_{CC,C++}FLAGS_<arch>, which, however,
was overwritten by the SetupKernel rule. This commit introduces new
global variables {HAIKU,HOST,TARGET}_WERROR_FLAGS[_<arch>], which
contain the additional -Werror flags to be applied for the architecture.
The config variable WARNINGS can be set to "treatAsErrors" to cause
-Werror and {HOST,TARGET}_WERROR_FLAGS[_<arch>] to be appended to the
compilation flags.
Fixes#10280.
Since the PM merge we now have way too many targets,
here jam clean just fails in execve() due to too long arguments.
jam clean is now very verbose but at least it works.
Another option could be to override the Clean rule itself
to clean in batch by splitting the list...
Patches welcome.
* All packaging architecture dependent variables do now have a
respective suffix and are set up for each configured packaging
architecture, save for the kernel and boot loader variables, which
are still only set up for the primary architecture.
For convenience TARGET_PACKAGING_ARCH, TARGET_ARCH, TARGET_LIBSUPC++,
and TARGET_LIBSTDC++ are set to the respective values for the primary
packaging architecture by default.
* Introduce a set of MultiArch* rules to help with building targets for
multiple packaging architectures. Generally the respective targets are
(additionally) gristed with the packaging architecture. For libraries
the additional grist is usually omitted for the primary architecture
(e.g. libroot.so and <x86>libroot.so for x86_gcc2/x86 hybrid), so that
Jamfiles for targets built only for the primary architecture don't
need to be changed.
* Add multi-arch build support for all targets needed for the stage 1
cross devel package as well as for libbe (untested).
* Update MimeSet rule to use the MIME DB the build system creates.
* Add CreateAppMimeDBEntries rule and call it from Link for targets that
might be applications that need to be registered with the MIME DB. For
the target the rule is invoked with it creates a directory into which
the entries for the types to be registered are written. The directory
is associated with the target via the HAIKU_MIME_DB_ENTRIES variable.
* AddFilesToContainer: If a target is added that has MIME DB entries,
also add those to the container.
* build_haiku_package: Call mimeset for the package contents.
first remove the target and its attributes (if any). Before gcc would
just unlink it and leak the attributes, which could lead to later
mixups, if the file's inode ID was re-used. As reported by Rene this
improves the attribute mixup situation, but doesn't solve it
completely. So that status quo is still the same: When using the
generic attribute emulation one has to build from the scratch to be
sure all attributes are fine.
* Got rid of superfluous whitespace.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@27385 a95241bf-73f2-0310-859d-f6bbb57e9c96
again. I'm not totally sure why that is, but the set-uid permission kept
disappearing.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@25036 a95241bf-73f2-0310-859d-f6bbb57e9c96
finally created a solution to avoid that: Header files that contain
configuration settings (and nothing else) go to build/config_headers.
To change settings, create a directory build/user_config_headers (which
is ignored by svn), copy the respective header there and modify it at
your leisure. Currently only tracing_config.h has been moved to the new
location, but more files will follow eventually. It is also recommended
to move optional macro definitions in Jamfile (as for BFS) to a config
header instead; the build system will then automatically rebuild on
changes.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24611 a95241bf-73f2-0310-859d-f6bbb57e9c96
so one can set it to the static libroot, if desired.
* Generic attribute emulation:
- Added build tool rm_attrs, a simple "rm" replacement, which also
removes the attributes directory for a given file.
- Added build/scripts/rm_attrs shell script, which wraps the
invocation of the rm_attrs tool. If it doesn't exist yet, the
ordinary rm is used.
- The RM jam variable refers to the rm_attrs script now, i.e. whenever
something is removed by the build system, the attributes are removed
too (if the build tool has already been built, that is).
- Removed the shell function attrrmrf() in build_haiku_image. We use
the rm_attrs tool instead, if necessary.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@24528 a95241bf-73f2-0310-859d-f6bbb57e9c96
* Added new rule HaikuSubInclude for more comfortable subdirectory inclusion.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20352 a95241bf-73f2-0310-859d-f6bbb57e9c96
stale dependencies after renaming or deleting object files.
This will avoid link error like the one that was caused by the
recent mesa update.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@20148 a95241bf-73f2-0310-859d-f6bbb57e9c96
one being $(1:S=$(SUFLIB)). Thus the wrong AR would be used when
the name passed to LibraryFromObjects didn't have the .a suffix yet.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@15029 a95241bf-73f2-0310-859d-f6bbb57e9c96
we use the libstdc++ (including it's headers) that comes with the
compiler.
* Apparently option "-I-" has been deprecated, which is why we now treat the
include stuff a bit differently.
* Removed avcodec from the Haiku image, since the library wouldn't build with
gcc 4, and I'm not in the mood to fix that (declaration of an array of an
incomplete type).
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@14876 a95241bf-73f2-0310-859d-f6bbb57e9c96
Augustin Cavalier