[haiku-commits] Re: BRANCH mmadia-github.separate-build-environment - headers/build/posix_target
- From: Matt Madia <mattmadia@xxxxxxxxx>
- To: haiku-commits@xxxxxxxxxxxxx
- Date: Sat, 4 Aug 2012 14:34:23 +0000
On 8/4/12, Ingo Weinhold <ingo_weinhold@xxxxxx> wrote:
> On 2012-08-04 at 02:49:12 [+0200], mmadia-github.separate-build-environment
> <community@xxxxxxxxxxxx> wrote:
>> diff --git a/headers/build/posix_target/target_stdint.h
>> b/headers/build/posix_target/target_stdint.h
>> new file mode 100644
>> index 0000000..2bb4be0
>> --- /dev/null
>> +++ b/headers/build/posix_target/target_stdint.h
> There are two ways to achieve that:
Just to make sure I understand ...
> 1. The prefixed versions are defined unconditionally. The unprefixed
> versions are defined conditionally. That latter can be defined based
> on the former.
e.g., #define FOO "some value" // becomes
#define _HAIKU_BUILD_FOO "some value"
...
#ifndef _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER
# define FOO _HAIKU_BUILD_FOO
...
#endif
e.g., typedef __haiku_int8 int8; // *could* become
typedef __haiku_build_haiku_int8 _haiku_build_int8;
...
#ifndef _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER
typedef _haiku_build_int8 int8
...
#endif
> 2. Both prefixed and unprefix versions are defined conditionally depending
> on the compilation mode. That means one cannot be defined based on the
> other.
Ohhh. So this is where your _HAIKU_BUILD_IDENTIFIER helper macro
implementation comes into play.
e.g., typedef __haiku_int8 int8; // becomes
typedef __haiku_build_haiku_int8 _HAIKU_BUILD_IDENTIFIER(int8);
and only that single line. There's no
#if[n]def _HAIKU_BUILD_LIBROOT_FUNCTION_WRAPPER block, as the
_HAIKU_BUILD_IDENTIFIER macro will handle the prefixing if necessary.
Then elsewhere e.g., in the function implemetations, "int8" would be
replaced with "_HAIKU_BUILD_IDENTIFIER(int8)".
But if approach 1 is used, then elsewhere in the code,
"int8" would be replaced with "_haiku_build_int8" ... right?
> This is more to type for the definition, but since the unprefixed version
> is always defined one can use that one whereever the type is referred to
> instead of the unhandy _HAIKU_BUILD_IDENTIFIER construct. So this is nice
> for often-used types like int32 or status_t. Since you do all the typing it
> is your decision when you want to use one way the other.
I'll go with this approach.
--mmadia
Other related posts:
