On Thu, Aug 13, 2015 at 11:33 AM, Johannes Berg
[off-list ref] wrote:

On Thu, 2015-08-13 at 09:55 -0700, Filipe Brandenburger wrote:

quoted

Long term, considering this is in AOSP and is part of eng/userdebug
builds, it's likely to be automatically available in future versions
of Android.

Yeah, but most vendors don't actually build/run/ship AOSP nor
necessarily an unmodified iw, so it's likely not all that helpful.

i think you misunderstand what AOSP is. this code is currently in AOSP
master, and thus in internal master, and thus in a future release.

quoted

We ended up having to tweak the Android.mk again in the AOSP tree,
since the current one is doing an "include" of the external Makefile,
which in turns overrides the default "clean" rule and leaks some
pattern rules such as %.o, etc. which affect the rest of Android
build. For more details, please take a look at this Gerrit:
https://android-review.googlesource.com/166104

I'm cc'ing Ying who spotted the problem and suggested the changes.

Thanks, but I'm not going to apply that patch in my tree - I don't want
to have to worry about the duplication of LOCAL_SRC_FILES.

quoted

One problem with the current approach is that there's duplication of
the names of the source files between Android.mk and Makefile, I was
thinking perhaps we could introduce a common.mk or sources.mk that's
included from both and only has the variables that can be used by
both? Suggestions are welcome.

That seems reasonable.

quoted

As mentioned in the initial thread, one option is to drop Android.mk
from upstream altogether and maintain it in our AOSP downstream.

Given what I just said above about vendor builds etc. not being AOSP,
that probably wouldn't be all that helpful; I'm pretty sure it'd make
our life more difficult so I don't really like that idea much.

johannes

-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.