sust...@250bpm.com said: > Mato, > > Indeed, that would be my greatest concern. We can't easily accept patches > > which add "Yet another build system", it creates too much of a maintenance > > overhead. > > > I'va asked Ghislain and the reason is that he's not familiar with > autotools. Still, the patch is perfectly valid. > > So the only question is how does autotools behave on Android. Would it > define ZMQ_HAVE_ANDROID? Or does it treat Android as a Linux flavour?
No idea here, sorry. If it's indeed just some missing functions, then the proper solution (and what I've been doing in e.g. the signaler code) is to write proper autoconf tests for those missing functions, and if they're not available do not use/emulate them; this is in fact the intent of autoconf, it's just that 0MQ has historically been doing: #if defined ZMQ_HAVE_SOME_OS || defined ZMQ_HAVE_OTHER_OS // Implementation 1 #elif defined ZMQ_HAVE_WEIRD_OS // Implementation 2 #else // Implementation 3 #endif This obviously doesn't scale well, the way autoconf is designed we should instead be doing: // Implementation #if defined ZMQ_HAVE_SOME_SYSCALL // SOME_SYSCALL-dependent bits #elif defined ZMQ_HAVE_OTHER_SYSCALL // OTHER_SYSCALL-dependent bits #else // Some fallback, if possible #endif The tests in configure should ensure a combination that makes sense is selected, if some *required* feature/syscall/... is not available then configure should fail. -mato _______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
