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 <[email protected]> wrote: > > 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 wrote: >> 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 / no-Bionic >> separation. >> (i.e. some of the libraries must be built with Bionic and use special >> facilities here, while at the same time must be built for the host >> using other ones). >> >> 2009/4/7 Fredrik Markström <[email protected] >> <mailto:[email protected]>> >> >> >> 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 specific question this time is if I'd better off using "#if >> !defined(__ARM_ARCH_4T__)" or "#if >> defined(__ARM_HAVE_HALFWORD_MULTIPLY)" in external/skia/.../SkMath.h >> >> /Fredrik >> >> >> >> >> > > > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [email protected] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
