On Thu, May 19, 2011 at 07:30:49PM +0200, Rafael Gieschke wrote: > > The point of uname_S is that it would be found automatically. Sadly, > > There is nothing helpful in uname to tell us that we are on android: > > Actually, you can't even call uname as I suspect that you would > normally not compile on Android (I don't think that gcc runs on > Android) but always cross-compile. Good point. Whatever support we provide will need to be user-configured, then. > > So I think we are probably stuck either with the user setting an ANDROID > > meta-flag that sets the other flags appropriately, or leaving it up to > > the user to provide a sane config.mak. > > Yes, I agree that leaving it up completely to the user to provide a > config.mak is a very good option too, especially as build environments > might be different and some might want to try building with Perl and > libcurl, which would require a config.mak anyhow. I don't know enough about Android development to know how much commonality there is between devices and builds. AFAIK, the Android spec itself only provides the Java-callable API. So for Unix-y stuff like this, I have no idea what is on stock Android versus Cyanogen for instance, or even if what is on stock varies from handset to handset. So yeah, we are probably better not even trying to provide a default set of flags for Android; we can support specific hacks (like your patches 1 and 2) but leave it up to individual build environments to enable them as appropriate. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html