All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sandeep Patil <sspatil@android.com>
To: ltp@lists.linux.it
Subject: [LTP] 回复:[PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build
Date: Fri, 12 Apr 2019 12:48:09 -0700	[thread overview]
Message-ID: <20190412194809.GE124555@google.com> (raw)
In-Reply-To: <ee797e09-e650-4869-60b7-f6e8e32844bb@xiaopeng.com>

On Sat, Apr 13, 2019 at 12:15:18AM +0800, 阮正旺 wrote:
> 
> -------- Original Message --------
> From: Petr Vorel
> Sent: Fri, 12 Apr 2019 08:28:14 +0200
> To: 阮正旺
> Cc: Sandeep Patil, Ltp, Steve Muckle
> Subject: Re: [LTP] 回复:[PATCH v1] include/mk/env_post.mk : enable
> __ANDROID__ definition for Android build
> > Hi Zhengwang,
> > 
> > > > > According to [1] android toolchain (I guess both AOSP and NDK toolchain) define
> > > > > __ANDROID__. Which is what I'd expect.
> > > > > Grepping aosp only dnsmasq and swiftshader use -D__ANDROID__ (these are from
> > > > > externals). -DANDROID is use more times (e.g. some drivers in hardware - ril,
> > > > > qcom, libsensors and wpa_supplicant).
> > > > >   From my point of view, instead of -D__ANDROID__ or -DANDROID I'd prefer to to have
> > > > > proper #ifdef HAVE_FOO guarders made by autotools checks. As android is not the
> > > > > only minor libc. But I understand it's not always possible and we already use
> > > > > some #ifdef __ANDROID__ in library sources and headers, so ack from myself to
> > > > > help compilation outside AOSP and without NDK.
> > > > Actually I was wrong. 1) I was using NDK toolchain. I'd expect it'd generate
> > > > __ANDROID__, but I don't see it in the output. 2) Building for android with
> > > > distro toolchain doesn't make sense as it wouldn't have Bionic.
> > > 1) Did you build outside AOSP? If so,  I think it is reasonable since
> > Yes, with android NDK (for Bionic and special toolchain tweeks).
> > Then I use ANDROID=1
> > 
> > > whatever __ANDROID__ or ANDROID are defined by Android build system instead
> > > of toolchain. I also tried to build the external/* thing and found ANDROID
> > > was actually generated. In my test, ANDROID seems to be the more suitable
> > > one, but in fact we can not build ltp inside AOSP because there is no
> > > Android.mk in ltp (please correct me if I am wrong...),  so ANDROID is
> > Yes, inside AOSP you need to use Android fork [1] which uses usual Android.bp.
> > Therefore AOSP does not use our build system.
> > 
> > > meaningless to us here. Actually, this is why I think this patch is still
> > > useful, since __ANDROID__ is enough to distinguish what to compile if
> > > ANDROID=1 is set with make.
> > > 2) In the case of cross-compilation, I think it still makes sense, since we
> > > can use the same toolchain, such as clang,  and build parameters (the
> > > specify the include headers and libs, etc) as AOSP. This is what I am doing
> > > now, you can see my steps I posted in my previous reply. But in this case,
> > > we need to obviously set -D__ANDROID__ in CFLAGS. After that , the process
> > > should be similar as we launch a build inside AOSP.
> > I don't know much about android toolchain, but IMHO there are some other tweaks
> > in their build system (to comply changes in Bionic), so not sure if it's even
> > possible to avoid using NDK for out-of-aosp tree. See also [2]. But that's a
> > question for for Android devs.
> 
> According to also [2], the situation gets clear now. All android targets
> should get __ANDROID__ defined by the compiler, but ANDROID only means 'this
> is AOSP' and is only for Windows targets. In our case, __ANDROID__ should be
> preferred.

Correct, and the build can still be make ANDROID=1 which translates to
-D__ANDROID__.

JFYI, there have been occasions when we changed something in bionic as a
result of an LTP tests, so those fixes will be missing for someone who is
using ndk for testing and building LTP.

That being said, thats a fairly small subset and is manageable. We can catch
those in reviews / patches very easily.

I like the idea of being able to build ouf-of-aosp, so I'm going to give this
a try now and will report.

- ssp
> 
> 
> Regards,
> 
> Zhengwang
> 
> > 
> > > Regards,
> > > Zhengwang
> > Kind regards,
> > Petr
> > 
> > [1] https://android.googlesource.com/platform/external/ltp/
> > [2] https://groups.google.com/forum/#!topic/android-ndk/cf9_f1SLXls

  reply	other threads:[~2019-04-12 19:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09  4:05 [LTP] [PATCH v1] include/mk/env_post.mk: enable __ANDROID__ definition for Android build Zhengwang Ruan
2019-04-09 16:45 ` [LTP] 回复:[PATCH " =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-10 14:16   ` Petr Vorel
2019-04-11  3:38     ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-11 16:27     ` Sandeep Patil
2019-04-11 17:37       ` Petr Vorel
2019-04-11 23:40         ` Petr Vorel
2019-04-12  4:45           ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-12  6:28             ` Petr Vorel
2019-04-12 16:15               ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-12 19:48                 ` Sandeep Patil [this message]
2019-04-16 12:27                   ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-17 16:39                     ` Sandeep Patil
2019-04-17 17:06                       ` Petr Vorel
2019-04-19 15:49                         ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-21 22:10                           ` Petr Vorel
2019-04-23 17:28                             ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-23 20:38                               ` Petr Vorel
2019-04-12  3:09       ` =?unknown-8bit?b?6Ziu5q2j5pe6?=
2019-04-24  9:14 ` [LTP] [PATCH " Petr Vorel
2019-04-24 19:23   ` Steve Muckle
2019-04-24 20:19     ` Petr Vorel
2019-04-25  3:08     ` =?unknown-8bit?b?6Ziu5q2j5pe6?=

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190412194809.GE124555@google.com \
    --to=sspatil@android.com \
    --cc=ltp@lists.linux.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.