Thread (17 messages) 17 messages, 4 authors, 2015-08-13

Re: [PATCH 2/2] iw: remove android-nl.c with unneeded workaround

From: enh <hidden>
Date: 2015-08-02 16:11:52

On Sat, Aug 1, 2015 at 11:57 PM, Arik Nemtsov [off-list ref] wrote:
On Fri, Jul 31, 2015 at 7:01 PM, enh [off-list ref] wrote:
quoted
no, because this is meant for the platform build system rather than
the NDK. although the NDK has a concept of target API level, the
platform only has "current".
Don't you have PLATFORM_VERSION?
http://androidxref.com/5.1.1_r6/xref/build/core/version_defaults.mk
yes, but that's an arbitrary string.
And I see it's already used in some places.
by OEM code that's expected to be obsolete anyway. if you only have to
list _past_ versions (and you only care about Google's Android, and
not, say, the Amazon fork), you can use PLATFORM_VERSION. but it
doesn't seem a good idea for general use.
My 2c is that it's a bad idea to break older version compatibility
when Android is not the owner of the project/git. Basically you don't
really have the same level of control over where this is used.
my 2c is that it's a bad idea to have an Android.mk that doesn't work
right now. and because libnl isn't part of the platform API, there's
no correct version version check for you to use. some OEMs may have
have that function longer than others; some may still not have it.
saying that libnl 2.0 is a prerequisite and your project won't build
without it sounds perfectly reasonable to me.

if this is really the only thing preventing your project from working
with libnl_2 though, why don't we just add it?

-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help