On Sat, Jul 21, 2018 at 2:34 PM Michael Richardson <m...@sandelman.ca> wrote:
> > enh <e...@google.com> wrote: > >> secur...@tcpdump.org is not an appropriate place to ask about > binaries. > >> Sometime on tcpdump-workers might be able to help you. > >> https://www.androidtcpdump.com/ also is around. > >> I don't know who runs it. > >> > >> I spent some time trying to integrate the Android (ASOP) build > system > >> Makefiles into tcpdump, but it never went upstream, and I ran out of > >> time. > > > as the AOSP maintainer of external/tcpdump and external/libpcap, i > don't > > think that would help you or me. it's usually just a pain for us > when an > > upstream project has an Android.mk because then we have to > coordinate for > > build system changes that no-one outside of AOSP actually cares > about. > > And if we could bring you into the fold, then you could maintain the file > you want? > even for projects where i have an upstream commit bit, it's not helpful to either side to have the Android.mk in the upstream project. Android's compiler toolchain gets updated frequently, so it's often necessary to slip in a -Wno-new-warning-that-a-project-doesn't-care-about or whatever. there's also the need to work around the mismatch between autoconf (or equivalent) and Android's single tree for four architectures with generated files checked in: that sometimes leads to Android.mk effectively taking over the role of config.h itself. and at the same time, there's no benefit to upstream from keeping an Android.mk that's only useful in AOSP and that they can't usually test themselves anyway. and why would they? even on very beefy machines, an AOSP build isn't quick. and the download is even worse. what _would_ be useful: 1. if it was easier for folks to build with the NDK. but we think it scales better if we get to the point where it's trivial to cross compile. like i said, if you know how to set up a suitable cross-compilation toolchain you can already build tcpdump out of the box with configure/make. and as i said, the next step is to remove the need to set up a cross-compilation toolchain ( https://android.googlesource.com/platform/ndk/+/master/docs/Roadmap.md). and i really need to get around to publishing a script that hides even that, so it's more of an "apt-get" kind of experience. we're working on it... 2. if AOSP was always up to date. i know historically a lot of projects were added to external/ and then left to rot, but my team has been trying to clean that up, and libpcap/tcpdump were actually fairly early beneficiaries. i removed all local hacks some time ago and the reason i'm on this mailing list is because there isn't a separate -announce mailing list :-) i have someone working on automating updates of projects hosted on github, though, so hopefully we'll be able to take the human out of the loop for libpcap this (1.9.0 release... > (luckily since we switched to Android.bp i haven't seen any upstream > > project even think it might be a good idea for them to have one of > those!) > > ha. > > -- > ] Never tell me the odds! | ipv6 mesh > networks [ > ] Michael Richardson, Sandelman Software Works | network > architect [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on > rails [ > > _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
