Ok, true. So the current patch is ok then ?
/Fredrik
On Wed, Apr 22, 2009 at 7:42 AM, Ben Leslie wrote:
>
> That doesn't really help (I think?). For packages that _can_ depend on
> Android, they can simply get the definitions from the cpu_features.h
> header file in bionic.
>
> For packages tha
That doesn't really help (I think?). For packages that _can_ depend on
Android, they can simply get the definitions from the cpu_features.h
header file in bionic.
For packages that _can't_ depend on Android, adding stuff to the build
system won't help, since they will all have their own build sys
I agree this would be nice, unfortunately gcc doesn't define
__ARM_ARCH (afaik). Should we add this to the build-system ?
(linux-arm.mk) or keep it the way it is now ?
/Fredrik
On Thu, Apr 9, 2009 at 3:27 PM, Sean McNeil wrote:
>
> I think it is also a good idea not to eliminate an architecture
I think it is also a good idea not to eliminate an architecture, but to
include the ones that are supported. For instance, it would probably be
better to say
#if defined(__arm__) && !defined(__thumb__) && (__ARM_ARCH__ >= 5)
if this code is supported on architectures 5 and above.
David Turner
Try to keep the code not depend on Bionic, but you can also conditionally
support it by testing for HAVE_ANDROID_OS
which is defined in all target Android build projects (except the simulator
ones), i.e.:
#ifdef HAVE_ANDROID_OS
...
#endif
that's how most of the framework code does its Bionic /
[Sean McNeil ]
>
> The whole idea is to minimize the changes to the code in external/* such
> that it has the possibility to be merged back to its source. Which is better
>
> a) use "#ifdef __ARM_ARCH_4T__" (which is standard to many people and
> already in Androids compilation line).
> or
> b
The whole idea is to minimize the changes to the code in external/* such
that it has the possibility to be merged back to its source. Which is better
a) use "#ifdef __ARM_ARCH_4T__" (which is standard to many people and
already in Androids compilation line).
or
b) "#ifdef ANDROID", "#include ",
I really don't see any reason to not use bionic in external. This would not
be the common case, because by definition external tends to be things that
exist outside of android so probably want to run elsewhere. But whether or
not they want to depend on bionic should really be up to the owner of t
Hi Fredrik,
IMO, external/* should not depend on bionic.
Fredrik Markström wrote:
> What is the general opinion about the code in external (for example
> skia, libjpg), can it depend on bionic-specifics like cpu-features.h
> or should we try to keep the external stuff independent ?
>
> The speci
