Improve the build system for building on Haiku

[mmadia]

quoted from ​http://www.freelists.org/post/haiku-development/R1a4-possible,13

[Currently] the build on Haiku will break whenever certain kinds changes in Haiku happen. The main reason for that is that, when building on Haiku, the build system tools are build against the build platform headers and libraries, but against the current headers and libraries on Linux, FreeBSD, and friends.

The theoretically simple solution is to use the latter method on Haiku as well. That, however, leads to clashes with the build platform headers and libraries, which at some point have to be used. The solution to that is to wrap all functionality used and symbolically map the wrappers to the names of the expected functionality (via macros, the FS shell uses a very similar approach). Essentially this cleanly separates the Haiku build environment from the build platform environment, from which the build on other platform benefits as well, as it allows to get rid of several hacks and work-arounds and also allows for dealing more easily with build platform quirks (like missing POSIX functionality, which is currently an issue on MacOS X).

As [Ingo] wrote before, this is a lot of tedious work, since wrappers for dozens of POSIX and Haiku headers and their functionality need to be written.

[mmadia]

Ingo, I'd like to start looking at this. Though, i'm not sure where/how to start. Could you give some more details and maybe even an example to model the work after?

[bonefish]

First of all let me repeat the disclaimer: This is a lot of tedious work. Moreover, it may turn out that the approach doesn't even work. E.g. I haven't fully thought through how to deal with code that uses the STL -- there are a few options but neither may work in the end.

Here's the goal we're aiming at: The build tools written for Haiku (like addattr, xres,...) need to be built for the build platform in such a way that the environment (i.e. the headers that are included when compiling) closely resembles the Haiku environment (the working directory version). And obviously the tools built this way must also work on the build platform.

To achieve this goal any header that is included by the build tools (recursively) must be provided by the build system. We do that already for the Haiku headers (headers/build/os), but it must also be done for the POSIX headers (not yet existent: headers/build/posix) with a few exceptions for headers provided by the compiler (e.g. stddef.h and stdarg.h). The headers BeOSBuildCompatibility.h and HaikuBuildCompatibility.h twist the build platform environment so that it looks more like Haiku's. Consequently they will no longer be needed, since we will provide a Haiku environment.

Providing the headers is only half of the deal. The build system must also provide the implementation for the stuff the headers declare. The current build system already does that for the Haiku specific part. There's a libbe_build.so (src/build/libbe) which implements the libbe API. There's also a libroot_build.so (src/build/libroot) which implements the Haiku specifics of the libroot API (attribute functions, find_directory(), etc.). libbe_build will remain mostly unchanged, but the libroot_build part will need to be extended to also cover all the POSIX functionality.

Obviously a lot of this functionality cannot be implemented from the scratch or it is at least not desirable to do so. Instead we want to map it to the build platform's implementation. And that's where things get tricky. You can't call the build platform's vfprintf() from the build system's vfprintf() implementation, since they have the same name. Moreover, if the build platform supports symbol preemption, we'd actually override the build platform's libc/libroot symbols. Hence the functions must be named differently. In fact all macros, types, and global variables need to be named differently, too, since otherwise they would clash with the ones from the build platform header which needs to be included to be able to call the build platform function.

This means that the build system headers must be designed to be included in two different ways. When included from the build tools' code they must define the standard functionality but at the same time map it to new names. When included from the libroot_build code that implements the functionality, they must define the functionality only with the new names.

As mentioned in the ticket description the FS shell does something similar. It needs to provide a Haiku kernel environment, so that the BFS (or other FSs) code can be built on the build platform. It provides a headers for the functionality to be emulated (e.g. headers/private/fs_shell/fssh_stat.h) where everything is defined with a fssh_/FSSH_ prefix. Furthermore it provides a header (headers/private/fs_shell/fssh_api_wrapper.h) that maps all prefixed names to the standard names via macros. The latter header is included in the BFS code (when built for the FS shell). Only the former header is included in the implementation of the functionality (e.g. src/tools/fs_shell/stat.cpp). That the headers don't have the standard names and that a single wrapper header was used, is just because it was simpler to do that in this context. The mapper macros could just as well have been defined in the individual headers, guarded by an #ifndef.

Basically that's the approach I was thinking of for the build tools as well. The mapping via macros should be done only for macros, though, since that potentially maps stuff one doesn't want to map (e.g. the macro for stat not only maps the stat() function and the stat structure, but also anything else with that name -- like the stat() method of some STL class). Instead structures and typedefs should just be defined with the respective name depending on the context of inclusion. Functions should be mapped via the asm name feature. That should be aided as much as possible via helper macros. Example of how that would look in a header:

// types/enums/...
typedef enum {
   _HAIKU_BUILD_IDENTIFIER(B_DESKTOP_DIRECTORY) = 0,
   _HAIKU_BUILD_IDENTIFIER(B_TRASH_DIRECTORY),
   ...
} _HAIKU_BUILD_IDENTIFIER(directory_which);

// functions
_HAIKU_BUILD_DECLARE_FUNCTION(
       status_t, find_directory,
               (_HAIKU_BUILD_IDENTIFIER(directory_which) which,
                _HAIKU_BUILD_IDENTIFIER(dev_t) volume, bool createIt,
                char* pathString, _HAIKU_BUILD_IDENTIFIER(int32) length))
// Note: To make things a bit shorter, for standard types like int32 or dev_t
// _haiku_build_* could always be defined and be (conditionally) mapped via
// typedef to the unprefixed type, so that _haiku_build_int32 could be
// written here.

// macros
#define FOO 0
#if __INTEL__
#  define LITTLE_ENDIAN 1
#endif

#ifndef _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER
#  define _HAIKU_BUILD_FOO FOO
#  ifdef LITTLE_ENDIAN
#    define _HAIKU_BUILD_LITTLE_ENDIAN LITTLE_ENDIAN
#  endif
#endif // _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER

In order to be able to include both the build system and the equally named build platform headers in the libroot_build sources, it is probably easiest to provide two build system headers for each standard header. E.g. there would be a headers/build/posix/stdio.h that only includes headers/build/posix_haiku/haiku_stdio.h which contains the actual stuff. The headers in headers/build/posix_haiku only include other haiku_* headers. Consequently the libroot_build code would not have the headers/build/posix path in the include search paths, so that it can include the build platform's stdio.h and haiku_stdio.h at the same time.

The libroot_build implementations should be pretty similar to the ones in the FS shell. I.e. they need to map types and values of parameters and (opposite direction) return values. In some cases more has to be done (like the attribute functions) but mostly the code for that should already be present in the current build system.

Regarding how to proceed, I'd recommend the following:

• Get rid of {BeOS,Haiku}BuildCompatibility.h.
• Add empty headers for all POSIX headers in headers/build/posix (simplifications may be possible, e.g. in the stdio* case -- stuff that exposes internals should best be omitted) and adjust the build system that they are included in the right contexts.
• Try building libroot_build. It will fail. Add the headers/build/posix_haiku headers and include them from the respective headers in headers/build/posix. Eventually everything will compile but fail to link. Implement the needed functions.
• If there is any, try building a build tool that only uses libroot functionality. Add the missing headers and libroot_build implementations it requires. Once it builds it should also work.
• Try building libbe_build. More POSIX headers and libroot_build functionality will be needed. Note that only libroot_build itself (possibly not even all files of it) should be built in _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER mode.
• Try building the remaining build tools and add all missing stuff.

I left out the STL issue. Code that needs a Haiku environment might also need the STL. This may or may not be a bigger problem. First of all, the STL headers must be prevented from including any build platform POSIX headers, so any that aren't in headers/build/posix yet need to be added. The purely templatized code that doesn't have an instantiation in libstdc++ will probably be fine. Other stuff may clash with the Haiku build environment, though (possibly only noticed when the tools using it crash). It probably also depends what parts of the STL are actually used. So I'm still hoping for the best. If that doesn't work, things get tricky. We could either try to provide a mini STL ourselves or build a complete one for our Haiku build environment from the build tools sources. Either approach may fail as well.

I'll attach a patch of the branch I was using for working on the issue. It isn't in any useful state. I had worked on one approach, decided not to go with it, and experimented with another one. So use as reference only. E.g. there's a definition of the _HAIKU_BUILD_DECLARE_FUNCTION() macro you can probably recycle and maybe you find other stuff that could be helpful as well.

[bonefish]

experimental state patch

[mmadia]

OK, some questions are starting to surface.

In your full-host-abstraction.diff, there's several diffs similar to

diff --git a/headers/build/posix/endian.h b/headers/build/posix/endian.h
new file mode 100644
index 0000000..601b693
--- /dev/null
+++ b/headers/build/posix/endian.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright 2011, Haiku, Inc. All Rights Reserved.
+ * Distributed under the terms of the MIT License.
+ */
+#ifndef _HAIKU_BUILD_ENDIAN_H
+#define _HAIKU_BUILD_ENDIAN_H
+
+
+#ifdef _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER
+#	include_next <endian.h>
+#endif
+
+
+#endif	/* _HAIKU_BUILD_ENDIAN_H */

Is the "include_next <header>" section part of the abandoned approach or should that be replicated?

Replying to bonefish:

This means that the build system headers must be designed to be included in two different ways. When included from the build tools' code they must define the standard functionality but at the same time map it to new names. When included from the libroot_build code that implements the functionality, they must define the functionality only with the new names

So an example of that would be your headers/build/os/storage/FindDirectory.h in your patch? With the second part being implemented by this code block:

+#ifndef _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER
+
+#define B_DESKTOP_DIRECTORY	HAIKU_BUILD_B_DESKTOP_DIRECTORY
+#define B_TRASH_DIRECTORY	HAIKU_BUILD_B_TRASH_DIRECTORY
...
+#endif	// ! _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER

Right? Or is this where headers/build/posix and headers/build/posix_haiku come into play? ... I'm a bit uncertain on how the headers would look comparatively.

Could you give an example of the stuff in stdio* to exclude from the headers/build/posix/stdio* counterparts?

Also, would you want me to push this branch to github?

[bonefish]

Replying to mmadia:

OK, some questions are starting to surface.

In your full-host-abstraction.diff, there's several diffs similar to

[...]

Is the "include_next <header>" section part of the abandoned approach or should that be replicated?

That is from the abandoned approach which wasn't using a separate headers/build/posix_haiku tree, so the only way to include the build platform headers in libroot_build was to do that with the #include_next.

Replying to bonefish:

This means that the build system headers must be designed to be included in two different ways. When included from the build tools' code they must define the standard functionality but at the same time map it to new names. When included from the libroot_build code that implements the functionality, they must define the functionality only with the new names

So an example of that would be your headers/build/os/storage/FindDirectory.h in your patch? With the second part being implemented by this code block:

+#ifndef _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER
+
+#define B_DESKTOP_DIRECTORY	HAIKU_BUILD_B_DESKTOP_DIRECTORY
+#define B_TRASH_DIRECTORY	HAIKU_BUILD_B_TRASH_DIRECTORY
...
+#endif	// ! _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER

Right? Or is this where headers/build/posix and headers/build/posix_haiku come into play? ... I'm a bit uncertain on how the headers would look comparatively.

The FindDirectory.h header is a bit of a special case, since it contains both a libroot and a libbe part (the C++ find_directory()). The libbe part doesn't need to be wrapped in any case, since we don't use the build platform's libbe, but implement all libbe functionality we need in libbe_build. For libroot we implement a libroot_build, but need to use the build platform's libroot. That's the reason for all this wrapping business.

The headers/build/os/storage/FindDirectory.h header should look like:

// ... some header guard

#include "os_haiku/storage/haiku_FindDirectory.h"

#ifdef __cplusplus

/* C++ interface */

class BVolume;
class BPath;

status_t find_directory(directory_which which, BPath* path,
    bool createIt = false, BVolume* volume = NULL);

#endif  /* __cplusplus */

// ... header guard end

Pure libroot headers just contain a single line including their posix_haiku respectively os_haiku counterpart. Pure libbe headers are basically a copy of the actual Haiku header in headers/os/..., in some cases possibly culled by some functionality (those headers already exist and may just need an update). For mixed headers like FindDirectory.h the libroot part goes to the companion header in os_haiku, while the libbe part remains.

The headers in posix_haiku and os_haiku should all look like the code snippet from my previous comment (plus header guards etc.). Though I just noticed the macro part is the wrong way around. It should look like:

#define _HAIKU_BUILD_FOO 0
#if __INTEL__
#  define _HAIKU_BUILD_LITTLE_ENDIAN 1
#endif

#ifndef _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER
#  define FOO _HAIKU_BUILD_FOO
#  ifdef _HAIKU_BUILD_LITTLE_ENDIAN
#    define LITTLE_ENDIAN _HAIKU_BUILD_LITTLE_ENDIAN
#  endif
#endif // _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER

I.e. the unprefixed macros should only be defined when not building the libroot wrapper functions. Alternatively it is also OK to define either one macro or the other:

#ifdef _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER
#  define _HAIKU_BUILD_FOO 0
#  if __INTEL__
#    define _HAIKU_BUILD_LITTLE_ENDIAN 1
#  endif
#else
#  define FOO 0
#  if __INTEL__
#    define LITTLE_ENDIAN 1
#  endif
#endif // _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER

That's actually what happens for types and functions, but for macros it is not possible to do that with a helper macro.

BTW, regarding the naming of posix_haiku, os_haiku and the contained headers, feel free to find better alternatives. Maybe "build" or "impl" would be a better prefix/suffix.

I forgot to mention: Currently there's headers/build/config_build. It is not named "config" because on Haiku it would clash with the build platform header directory. With the new approach it should be renamed back to "config" so that it does shadow the build platform's header directory, just like "posix", also with a "config_haiku" counterpart.

Could you give an example of the stuff in stdio* to exclude from the headers/build/posix/stdio* counterparts?

The stdio_pre.h and stdio_post.h headers are implementation details. They are never included by client code. So they can be omitted (or to be certain, create empty files in their stead). Their contents should be revised and merged into stdio.h. FILE should by defined as an opaque type, libio.h should never be included (create an empty file instead), fgetc() and fputc() should be defined as function prototypes, not macros or inline functions. stdio_ext.h may not be needed either. Start with an empty file and only add something, if actually used.

Also, would you want me to push this branch to github?

Absolutely. If you add it to the commit list I'll try to review what you're doing.

[mmadia]

Replying to bonefish:

Pure libroot headers just contain a single line including their posix_haiku respectively os_haiku counterpart. Pure libbe headers are basically a copy of the actual Haiku header in headers/os/..., in some cases possibly culled by some functionality (those headers already exist and may just need an update). For mixed headers like FindDirectory.h the libroot part goes to the companion header in os_haiku, while the libbe part remains.

How can I determine which headers are pure libroot, pure libbe or a combination?

Are the changes relating to HaikuHostBuildConfig.h and HAIKU_HOST_FEATURE_* in your patch to be re-used?

Also, would you want me to push this branch to github?

Absolutely. If you add it to the commit list I'll try to review what you're doing.

Done and added to haiku-commits list, as you may know by now. ​https://github.com/mmadia/haiku/commits/separate-build-environment

[bonefish]

Replying to mmadia:

Replying to bonefish:

Pure libroot headers just contain a single line including their posix_haiku respectively os_haiku counterpart. Pure libbe headers are basically a copy of the actual Haiku header in headers/os/..., in some cases possibly culled by some functionality (those headers already exist and may just need an update). For mixed headers like FindDirectory.h the libroot part goes to the companion header in os_haiku, while the libbe part remains.

How can I determine which headers are pure libroot, pure libbe or a combination?

The exact definition would be: Any function that is implemented in libroot as well as any type, constant, or macro that is used in libroot (directly or indirectly (including also stuff that is just used to define other stuff that is used in libroot)) is considered libroot functionality for our purpose. So, when in doubt, grep can help to ascertain that fact.

As a rule of thumb: Everything in config/, posix/, and os/kernel is libroot functionality. A few things in os/support are libroot functionality as well (SupportDefs.h, Errors.h, ByteOrder.h, TLS.h, parsedate.h, partially TypeConstants.h (the enum, but not the B_URL_* constants)). That leaves the most part of os/. Anything that is C++ (i.e. classes or functions with C++ interface) is not. Any function exported as extern "C" should be checked, though, since it is likely libroot.

Are the changes relating to HaikuHostBuildConfig.h and HAIKU_HOST_FEATURE_* in your patch to be re-used?

Probably. In case you haven't looked closer at it: HaikuHostBuildConfig.h is generated in src/build/configure. That's a poor man's version of an autotools generated configure script, finding out available functionality and other properties of the build platform. For some of the stuff it is currently used in my patch, it might not be necessary. E.g. it determines whether certain string functions are available and based on that conditionally builds those into libroot_build. This shouldn't be done that way. Instead those functions should -- like other libroot functionality -- always be mapped to _haiku_build_* versions by the build headers and then implemented in libroot_build. To keep it simple, I would adjust the sources of those string functions (in src/system/libroot/posix/string/) to include the build header and define a _haiku_build_ prefixed function when built with _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER. Or, if very simple, just copy the function's implementation.

[mmadia]

Just to make sure, can all references to libHaikuCompat / libhaikucompat_build.a be removed? If i understand correctly, that will remove BeOS as a supported build platform.

[bonefish]

Replying to mmadia:

Just to make sure, can all references to libHaikuCompat / libhaikucompat_build.a be removed? If i understand correctly, that will remove BeOS as a supported build platform.

Not really. Or actually yes (together with the support for older Haiku versions), but that support would (or could) be re-added in the libroot_build implementation in a more generic way. Linux and FreeBSD are even less Haiku compatible and still we will support them. Essentially the headers/build headers and the lib*_build libraries will provide a complete host abstraction layer. That is code written for Haiku can be built without changes using those headers and libraries. The library implementations in turn do the heavy lifting of mapping the functionality to implement to host platform functionality. Though in many cases the latter will just be portable POSIX functionality.

[mmadia]

For now I'm skipping the HaikuHostBuildConfig.h related changes.

The build system is now at a point, where it's looking for headers in headers/build/target_posix (the name chosen instead of posix_haiku). It's also complaining about the typedefs in headers/build/config_build/types.h and in headers/build/os/support/SupportDefs.h Could you post a snippet on how you want a typedef in ​headers/build/config_build/types.h updated? Between the patch and your comments, I'm not following how it should look.

If it helps, here's the output. Thanks.

[mmadia@fBSD ~/separate-build-environment/haiku]$ jam -q libroot.so
...patience...
...found 5182 target(s)...
...updating 1071 target(s)...
C++ generated/objects/freebsd/x86/release/build/libroot/atomic.o 
In file included from headers/build/os/support/Errors.h:9,
                 from headers/build/os/support/SupportDefs.h:15,
                 from src/build/libroot/atomic.cpp:6:
headers/build/posix/limits.h:9:40: error: posix_target/target_limits.h: No such file or directory
In file included from headers/build/os/support/SupportDefs.h:17,
                 from src/build/libroot/atomic.cpp:6:
headers/build/posix/inttypes.h:9:42: error: posix_target/target_inttypes.h: No such file or directory
In file included from headers/build/os/support/SupportDefs.h:18,
                 from src/build/libroot/atomic.cpp:6:
headers/build/posix/sys/types.h:9:43: error: posix_target/sys/target_types.h: No such file or directory
In file included from headers/build/os/support/SupportDefs.h:12,
                 from src/build/libroot/atomic.cpp:6:
headers/build/config_build/types.h:19: error: '_HAIKU_BUILD_FEATURE_int8' does not name a type
headers/build/config_build/types.h:20: error: '_HAIKU_BUILD_FEATURE_uint8' does not name a type
headers/build/config_build/types.h:21: error: '_HAIKU_BUILD_FEATURE_int16' does not name a type
headers/build/config_build/types.h:22: error: '_HAIKU_BUILD_FEATURE_uint16' does not name a type
headers/build/config_build/types.h:23: error: '_HAIKU_BUILD_FEATURE_int32' does not name a type
headers/build/config_build/types.h:24: error: '_HAIKU_BUILD_FEATURE_uint32' does not name a type
headers/build/config_build/types.h:25: error: '_HAIKU_BUILD_FEATURE_int64' does not name a type
headers/build/config_build/types.h:26: error: '_HAIKU_BUILD_FEATURE_uint64' does not name a type
headers/build/config_build/types.h:28: error: '__haiku_build_haiku_std_int8' does not name a type
headers/build/config_build/types.h:29: error: '__haiku_build_haiku_std_uint8' does not name a type
headers/build/config_build/types.h:30: error: '__haiku_build_haiku_std_int16' does not name a type
headers/build/config_build/types.h:31: error: '__haiku_build_haiku_std_uint16' does not name a type
headers/build/config_build/types.h:32: error: '__haiku_build_haiku_std_int32' does not name a type
headers/build/config_build/types.h:33: error: '__haiku_build_haiku_std_uint32' does not name a type
headers/build/config_build/types.h:34: error: '__haiku_build_haiku_std_int64' does not name a type
headers/build/config_build/types.h:35: error: '__haiku_build_haiku_std_uint64' does not name a type
headers/build/config_build/types.h:42: error: '__haiku_build_haiku_int32' does not name a type
headers/build/config_build/types.h:43: error: '__haiku_build_haiku_uint32' does not name a type
headers/build/config_build/types.h:50: error: '__haiku_build_haiku_int32' does not name a type
headers/build/config_build/types.h:51: error: '__haiku_build_haiku_uint32' does not name a type
headers/build/config_build/types.h:104: error: '__haiku_build_haiku_addr_t' does not name a type
headers/build/config_build/types.h:122: error: '__haiku_build_haiku_std_int8' does not name a type
headers/build/config_build/types.h:123: error: '__haiku_build_haiku_std_uint8' does not name a type
headers/build/config_build/types.h:124: error: '__haiku_build_haiku_std_int16' does not name a type
headers/build/config_build/types.h:125: error: '__haiku_build_haiku_std_uint16' does not name a type
headers/build/config_build/types.h:126: error: '__haiku_build_haiku_std_int32' does not name a type
headers/build/config_build/types.h:127: error: '__haiku_build_haiku_std_uint32' does not name a type
headers/build/config_build/types.h:128: error: '__haiku_build_haiku_std_int64' does not name a type
headers/build/config_build/types.h:129: error: '__haiku_build_haiku_std_uint64' does not name a type
headers/build/config_build/types.h:131: error: '__haiku_build_haiku_int8' does not name a type
headers/build/config_build/types.h:132: error: '__haiku_build_haiku_uint8' does not name a type
headers/build/config_build/types.h:133: error: '__haiku_build_haiku_int16' does not name a type
headers/build/config_build/types.h:134: error: '__haiku_build_haiku_uint16' does not name a type
headers/build/config_build/types.h:135: error: '__haiku_build_haiku_int32' does not name a type
headers/build/config_build/types.h:136: error: '__haiku_build_haiku_uint32' does not name a type
headers/build/config_build/types.h:137: error: '__haiku_build_haiku_int64' does not name a type
headers/build/config_build/types.h:138: error: '__haiku_build_haiku_uint64' does not name a type
headers/build/config_build/types.h:140: error: '__haiku_build_haiku_saddr_t' does not name a type
headers/build/config_build/types.h:141: error: '__haiku_build_haiku_addr_t' does not name a type
headers/build/config_build/types.h:142: error: '__haiku_build_haiku_phys_saddr_t' does not name a type
headers/build/config_build/types.h:143: error: '__haiku_build_haiku_phys_addr_t' does not name a type
headers/build/config_build/types.h:162: error: '__haiku_build_haiku_generic_addr_t' does not name a type
In file included from src/build/libroot/atomic.cpp:6:
headers/build/os/support/SupportDefs.h:22: error: '__haiku_build_haiku_int8' does not name a type
headers/build/os/support/SupportDefs.h:23: error: '__haiku_build_haiku_uint8' does not name a type
headers/build/os/support/SupportDefs.h:24: error: '__haiku_build_haiku_int16' does not name a type
headers/build/os/support/SupportDefs.h:25: error: '__haiku_build_haiku_uint16' does not name a type
headers/build/os/support/SupportDefs.h:26: error: '__haiku_build_haiku_int32' does not name a type
headers/build/os/support/SupportDefs.h:27: error: '__haiku_build_haiku_uint32' does not name a type
headers/build/os/support/SupportDefs.h:28: error: '__haiku_build_haiku_int64' does not name a type
headers/build/os/support/SupportDefs.h:29: error: '__haiku_build_haiku_uint64' does not name a type
headers/build/os/support/SupportDefs.h:32: error: 'haiku_build_int8' does not name a type
headers/build/os/support/SupportDefs.h:33: error: 'haiku_build_uint8' does not name a type
headers/build/os/support/SupportDefs.h:34: error: 'haiku_build_int16' does not name a type
headers/build/os/support/SupportDefs.h:35: error: 'haiku_build_uint16' does not name a type
headers/build/os/support/SupportDefs.h:36: error: 'haiku_build_int32' does not name a type
headers/build/os/support/SupportDefs.h:37: error: 'haiku_build_uint32' does not name a type
headers/build/os/support/SupportDefs.h:38: error: 'haiku_build_int64' does not name a type
headers/build/os/support/SupportDefs.h:39: error: 'haiku_build_uint64' does not name a type
headers/build/os/support/SupportDefs.h:55: error: 'haiku_build_int32' does not name a type
headers/build/os/support/SupportDefs.h:56: error: 'haiku_build_int64' does not name a type
headers/build/os/support/SupportDefs.h:57: error: 'haiku_build_int64' does not name a type
headers/build/os/support/SupportDefs.h:58: error: 'haiku_build_uint32' does not name a type
headers/build/os/support/SupportDefs.h:59: error: 'haiku_build_uint32' does not name a type
headers/build/os/support/SupportDefs.h:61: error: '__haiku_build_haiku_phys_addr_t' does not name a type
headers/build/os/support/SupportDefs.h:62: error: 'haiku_build_phys_addr_t' does not name a type
headers/build/os/support/SupportDefs.h:64: error: '__haiku_build_haiku_generic_addr_t' does not name a type
headers/build/os/support/SupportDefs.h:65: error: 'haiku_build_generic_addr_t' does not name a type
headers/build/os/support/SupportDefs.h:195: error: 'haiku_build_int32' does not name a type
headers/build/os/support/SupportDefs.h:197: error: 'haiku_build_int32' does not name a type
headers/build/os/support/SupportDefs.h:201: error: 'haiku_build_int32' does not name a type
headers/build/os/support/SupportDefs.h:203: error: 'haiku_build_int32' does not name a type
headers/build/os/support/SupportDefs.h:205: error: 'haiku_build_int32' does not name a type
headers/build/os/support/SupportDefs.h:207: error: 'haiku_build_int32' does not name a type
headers/build/os/support/SupportDefs.h:209: error: 'haiku_build_int64' does not name a type
headers/build/os/support/SupportDefs.h:211: error: 'haiku_build_int64' does not name a type
headers/build/os/support/SupportDefs.h:215: error: 'haiku_build_int64' does not name a type
headers/build/os/support/SupportDefs.h:217: error: 'haiku_build_int64' does not name a type
headers/build/os/support/SupportDefs.h:219: error: 'haiku_build_int64' does not name a type
headers/build/os/support/SupportDefs.h:221: error: 'haiku_build_int64' does not name a type
src/build/libroot/atomic.cpp:9: error: 'haiku_build_int32' does not name a type
src/build/libroot/atomic.cpp:18: error: 'haiku_build_int32' does not name a type
src/build/libroot/atomic.cpp:29: error: 'haiku_build_int32' does not name a type
src/build/libroot/atomic.cpp:38: error: 'haiku_build_int32' does not name a type
src/build/libroot/atomic.cpp:47: error: 'haiku_build_int32' does not name a type
src/build/libroot/atomic.cpp:56: error: 'haiku_build_int32' does not name a type
src/build/libroot/atomic.cpp:63: error: 'haiku_build_int64' does not name a type
src/build/libroot/atomic.cpp:71: error: 'haiku_build_int64' does not name a type
src/build/libroot/atomic.cpp:81: error: 'haiku_build_int64' does not name a type
src/build/libroot/atomic.cpp:89: error: 'haiku_build_int64' does not name a type
src/build/libroot/atomic.cpp:97: error: 'haiku_build_int64' does not name a type
src/build/libroot/atomic.cpp:105: error: 'haiku_build_int64' does not name a type

cc -c "src/build/libroot/atomic.cpp" -O -Wall -Wno-trigraphs -Wno-ctor-dtor-privacy -Woverloaded-virtual -Wpointer-arith -Wcast-align -Wsign-compare -Wno-multichar -DHAIKU_BUILD_ATTRIBUTES_DIR=\"/home/mmadia/separate-build-environment/haiku/generated/attributes\" -D_HAIKU_BUILD_DONT_REMAP_FD_FUNCTIONS=1 -D_ZETA_USING_DEPRECATED_API_=1 -D_ZETA_TS_FIND_DIR_=1 -nostdinc -nostdinc++ -fPIC -DARCH_x86 -D_NO_INLINE_ASM -D__INTEL__ -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DHAIKU_HOST_USE_XATTR -DHAIKU_HOST_PLATFORM_FREEBSD -iquote build/user_config_headers -iquote build/config_headers -iquote src/build/libroot -iquote generated/objects/common/build/libroot -iquote generated/objects/freebsd/x86/common/build/libroot -iquote generated/objects/haiku/x86/common/build/libroot -I headers/build -I headers/build/os -I headers/build/os/app -I headers/build/os/drivers -I headers/build/os/kernel -I headers/build/os/interface -I headers/build/os/storage -I headers/build/os/support -I headers/build/private/kernel -I headers/build/private/system -I headers/build/host/freebsd -I headers/build -I headers/build/posix -I headers/build/os -I headers/build/os/app -I headers/build/os/drivers -I headers/build/os/kernel -I headers/build/os/interface -I headers/build/os/locale -I headers/build/os/opengl -I headers/build/os/storage -I headers/build/os/support -I headers/build/private -o "generated/objects/freebsd/x86/release/build/libroot/atomic.o" ;

...failed C++ generated/objects/freebsd/x86/release/build/libroot/atomic.o ...

BUILD FAILURE:
...failed updating 1 target(s)...
...skipped 3 target(s)...
[mmadia@fBSD ~/separate-build-environment/haiku]$ 

[bonefish]

Replying to mmadia:

For now I'm skipping the HaikuHostBuildConfig.h related changes.

As written before you can omit the string function stuff, but you're going to need the _HAIKU_BUILD_FEATURE_[u]int*. All the "* does not name a type" errors should clear up once they are defined.

The build system is now at a point, where it's looking for headers in headers/build/target_posix (the name chosen instead of posix_haiku). It's also complaining about the typedefs in headers/build/config_build/types.h and in headers/build/os/support/SupportDefs.h Could you post a snippet on how you want a typedef in ​headers/build/config_build/types.h updated? Between the patch and your comments, I'm not following how it should look.

I hope my mail on the commit list helps.

[mmadia@fBSD ~/separate-build-environment/haiku]$ jam -q libroot.so

You can start smaller, like with building libroot_build.so. libroot.so will only build when most of the build tools already work. You won't get there before not only libroot_build but also libbe_build build.

...patience...
...found 5182 target(s)...
...updating 1071 target(s)...
C++ generated/objects/freebsd/x86/release/build/libroot/atomic.o 
In file included from headers/build/os/support/Errors.h:9,
                 from headers/build/os/support/SupportDefs.h:15,

As written in my mail, those headers shouldn't be included. The "headers/build/os", "headers/build/posix", etc. directories shouldn't even be in the header search path when compiling atomic.c.

from src/build/libroot/atomic.cpp:6:

headers/build/posix/limits.h:9:40: error: posix_target/target_limits.h: No such file or directory In file included from headers/build/os/support/SupportDefs.h:17,

from src/build/libroot/atomic.cpp:6:

headers/build/posix/inttypes.h:9:42: error: posix_target/target_inttypes.h: No such file or directory In file included from headers/build/os/support/SupportDefs.h:18,

from src/build/libroot/atomic.cpp:6:

headers/build/posix/sys/types.h:9:43: error: posix_target/sys/target_types.h: No such file or directory

Well, the headers must be added. :-)

[mmadia]

based off full-host-abstraction.diff

[mmadia]

With attachment:HAIKU_HOST_FEATURE.patch​ applied, I get the following linking error on FreeBSD. Any ideas what needs to be fixed?

[mmadia@fBSD ~/separate-build-environment/haiku]$  ./configure --use-xattr --use-gcc-pipe  --cross-tools-prefix generated/cross-tools/bin/i586-pc-haiku-
...patience...
...found 25 target(s)...
...updating 3 target(s)...
C++ generated/objects/freebsd/x86/release/build/configure/test_int_types.o 
Link generated/objects/freebsd/x86/release/build/configure/test_int_types 
generated/objects/freebsd/x86/release/build/configure/test_int_types.o:(.eh_frame+0x11): undefined reference to `__gxx_personality_v0'

cc -Xlinker --no-as-needed -lm -o "generated/objects/freebsd/x86/release/build/configure/test_int_types"   "generated/objects/freebsd/x86/release/build/configure/test_int_types.o" \
   \


...failed Link generated/objects/freebsd/x86/release/build/configure/test_int_types ...

BUILD FAILURE:
...failed updating 1 target(s)...
...skipped 1 target(s)...
...updated 1 target(s)...
[mmadia@fBSD ~/separate-build-environment/haiku]$ 

[mmadia]

Replying to mmadia:

With attachment:HAIKU_HOST_FEATURE.patch​ applied, I get the following linking error on FreeBSD. Any ideas what needs to be fixed?

With some help on IRC, updating src/build/configure/Jamfile to be ConfigureRunProgram test_int_types : test_int_types.cpp : $(HOST_LIBSTDC++); was the ticket.

[mmadia]

As a quick summary, 18 headers are done out of 123 (judging by find . -type f | wc -l in headers/build/[config, os, posix]). For jam -q libroot_build.so , src/build/libroot/atomic.cpp and src/build/libroot/byterorder.cpp compile and currently fails on errors.cpp.

Replying to bonefish:

I left out the STL issue. Code that needs a Haiku environment might also need the STL. This may or may not be a bigger problem. First of all, the STL headers must be prevented from including any build platform POSIX headers, so any that aren't in headers/build/posix yet need to be added. The purely templatized code that doesn't have an instantiation in libstdc++ will probably be fine. Other stuff may clash with the Haiku build environment, though (possibly only noticed when the tools using it crash). It probably also depends what parts of the STL are actually used. So I'm still hoping for the best. If that doesn't work, things get tricky. We could either try to provide a mini STL ourselves or build a complete one for our Haiku build environment from the build tools sources. Either approach may fail as well.

And that brings us to ​errors.cpp

#include <map>

using namespace std;

static map<int, int> sToHaikuErrorMap;
static map<int, int> sToHostErrorMap;
static bool sErrorMapsInitialized = false;

How should we proceed?

[mmadia]

Looking at your attachment:full-host-abstraction.diff​ , in src/build/libroot/Jamfile

@@ -53,7 +58,7 @@ if $(HOST_PLATFORM) = freebsd {
 local librootSources =
 	atomic.cpp
 	byteorder.cpp
-	errors.cpp
+#	errors.cpp
 	find_directory.cpp
 	fs.cpp
 	fs_attr.cpp

Is that a change that should be copied in my branch? Outside of src/build/libroot/errors.cpp, its functions are only used in src/tools/fs_shell/errno.cpp and headers/build/BeOSBuildCompatibility.h 

[bonefish]

Replying to mmadia:

As a quick summary, 18 headers are done out of 123 (judging by find . -type f | wc -l in headers/build/[config, os, posix]). For jam -q libroot_build.so , src/build/libroot/atomic.cpp and src/build/libroot/byterorder.cpp compile and currently fails on errors.cpp.

[...]

And that brings us to ​errors.cpp

[...]

How should we proceed?

That is really not the problematic case. The libroot_build implementations should be able to use the STL just fine. I doubt the errors have anything to do with that. The obvious problems are:

• The concerned target_* headers must be included, too.
• The ADD_ERROR() macro needs to be adjusted -- it uses the prefix HAIKU_ for the Haiku constants.

I think it has to work differently, though. We completely wrap all functionality the client code uses, so for instance _haiku_build_strerror() will only see the error codes we define. Consequently Haiku's strerror() code can be copied (with the prefixes, of course). _haiku_build_errnop() can simply return the pointer to a static int variable (let's call it sErrno). We still need the mapping between Haiku and build platform error codes, but at different times, namely when functions that return error codes or set or read errno are invoked. In pseudo code this would work like:

_haiku_build_ssize_t
_haiku_build_write(int fd, const void* buffer, size_t count)
{
    ssize_t written = write(...);
    if (written < 0)
       sErrno = convert_to_haiku_error(errno);
    return written;
}

Where convert_to_haiku_error() would be named something suitable with a prefix, sErrno wouldn't be accessible outside of "errors.cpp", so there needs to be a setter function for that purpose (since that will be common, there should be one that directly sets from errno).

[mmadia]

My concern is that I'm not sure how to work around that code snippet in errors.cpp, as it throws this error:

C++ /home/mmadia/separate-build-environment/generated.x86gcc2/objects/freebsd/x86/release/build/libroot/errors.o 
In file included from /usr/include/sys/_types.h:33,
                 from /usr/include/stddef.h:39,
                 from /usr/include/c++/4.2/cstddef:51,
                 from /usr/include/c++/4.2/cstring:51,
                 from /usr/include/c++/4.2/bits/stl_algobase.h:66,
                 from /usr/include/c++/4.2/bits/stl_tree.h:67,
                 from /usr/include/c++/4.2/map:65,
                 from /home/mmadia/separate-build-environment/haiku/src/build/libroot/errors.cpp:10:
/usr/include/machine/_types.h:43:2: error: #error this file needs sys/cdefs.h as a prerequisite
...

[bonefish]

Replying to mmadia:

My concern is that I'm not sure how to work around that code snippet in errors.cpp, as it throws this error:

[...]

There's probably something wrong with your compile line. For the libroot_build code "headers/build/posix" must not be in the include search path. At least that's the only reason I can think of ATM why the correct <sys/cdefs.h> wouldn't have been included (since "/usr/include/stddef.h" does include it before <sys/_types.h>).

[mmadia]

Looking at the headers in that error message, I noticed that our posix_target/target_cdefs.h defines _SYS_CDEFS_H, whereas /usr/include/sys/cdefs.h defines _SYS_CDEFS_H_ The latter is what /usr/include/machine/_types.h is requiring

/usr/include/stddef.h

#ifndef _STDDEF_H_
#define _STDDEF_H_

#include <sys/cdefs.h>
#include <sys/_null.h>
#include <sys/_types.h>
...

/usr/include/sys/_types.h

#ifndef _SYS__TYPES_H_
#define _SYS__TYPES_H_

#include <sys/cdefs.h>
#include <machine/_types.h>
...

/usr/include/machine/_types.h

#ifndef _MACHINE__TYPES_H_
#define _MACHINE__TYPES_H_

#ifndef _SYS_CDEFS_H_
#error this file needs sys/cdefs.h as a prerequisite
#endif

#define __NO_STRICT_ALIGNMENT
...

Should our posix_target/target_cdefs.h also define _SYS_CDEFS_H_ ?

[mmadia]

Looking at the invocations of UseHeaders in relation to jamming libroot_build.so, "build/posix" is not added.

Here's some output that may be questionable. (rule UseHeaders was edited to ouput the subdirectory in which that particular UseHeaders rule was called)

• ... Subdir: [ /mmadia/haiku/src/tools/bfs_shell ] UseHeaders: [ /mmadia/haiku/headers/build/os ] :[true]
• ... Subdir: [ /mmadia/haiku/src/tools/fs_shell ] UseHeaders: [ /mmadia/haiku/headers/build/os ] :[true]
• the CC command somehow does have -I /mmadia/haiku/headers/build/posix -I /mmadia/haiku/headers/build/os

But ... all of the headers in /mmadia/haiku/headers/build/posix are empty, aside from #include "posix_target/target_*". All of their header guards are prefixed with _HAIKU_BUILD[_], so I don't see how build/posix being included would negatively affect the build. Though I'm still not sure how it's being added to the include path to begin with, either.

[mmadia]

This might be the reason why the included headers are different than what is expected/needed...

First, ​libroot's Jamfile sets USES_BE_API on librootSources. The entire implications of USES_BE_API is still unclear, but it seems that at least it's responsible for including build/posix/ and build/os/.

For non-BeOS compatible hosts, ​BuildSetup sets HOST_BE_API_HEADERS to include both build/posix, build/os/, and other directories.

In MainBuildRules, ​rule BuildPlatformMain propagates USES_BE_API to the objects in librootSources.

Then finally in OverriddenJamRules, ​rule Object adds HOST_BE_API_HEADERS to sysHeaders. Adding an Echo at line 99, this output snippet backs this idea up

... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/os_target ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/os_target/app ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/os_target/drivers ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/os_target/kernel ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/os_target/interface ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/os_target/storage ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/os_target/support ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/posix_target ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  UseHeaders: [ haiku/headers/build/private/kernel haiku/headers/build/private/system ]  :[true] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 
... Subdir: [ haiku/src/build/libroot ]  OverriddenJamRules:Object: [ generated.x86gcc2/build haiku/headers/build haiku/headers/build/posix haiku/headers/build/os haiku/headers/build/os/app haiku/headers/build/os/drivers haiku/headers/build/os/kernel haiku/headers/build/os/interface haiku/headers/build/os/locale haiku/headers/build/os/opengl haiku/headers/build/os/storage haiku/headers/build/os/support haiku/headers/build/private ] 

Does this sound correct?

[bonefish]

The purpose of USES_BE_API is to enable a Haiku-ish environment for code built for the host platform. So it should not be set for libroot_build. It should should be set for libbe_build and all the tools that use the Be API (xres, settype, etc.). The latter should happen already.

[waddlesplash]

We now properly use libroot_build on Haiku hosts also, so we have the same level of host abstraction that we do on POSIX systems.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone