[PATCH 0/3] Android support

[Pekka Paalanen]

On Fri, 12 Oct 2012 15:27:27 -0700
Eric Anholt <eric at anholt.net> wrote:

> Negreanu Marius <groleo at gmail.com> writes:
> 
> > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli <tapani.palli at intel.com> wrote:
> >> On 10/10/2012 08:05 PM, Chad Versace wrote:
> >>> On 10/07/2012 10:50 PM, Tapani Pälli wrote:
> >>>> Upstreaming old set of patches here to enable Android support in libdrm.
> >>>> Some little rebasing was required for the first one.
> >>>>
> >>>> Chad Versace (2):
> >>>>   libdrm,intel: Factor source file lists into sources.mk
> >>>>   libdrm,intel: Add Android makefiles (v2)
> >>>>
> >>>> Haitao Huang (1):
> >>>>   Android.mk: use LOCAL_COPY_HEADERS to export headers.
> >>>>
> >>>>  Android.mk        | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>  Makefile.am       |  9 ++++----
> >>>>  intel/Android.mk  | 57 ++++++++++++++++++++++++++++++++++++++++++++++++++
> >>>>  intel/Makefile.am |  9 ++++----
> >>>>  intel/sources.mk  | 30 +++++++++++++++++++++++++++
> >>>>  sources.mk        | 30 +++++++++++++++++++++++++++
> >>>
> >>> This series looks good to me. Before committing, though, I'd like to see either
> >>> an Acked-by or an "Sure, whatever" from one of the regular libdrm_intel committers.
> >>
> >> Thanks for checking it out. I've tried out androgenizer as Eric
> >> suggested but not really convinced we would like to start using it.
> >
> > To bring an pro-argument for Tapani, this is how it looks to make it
> > work with androgenizer.
> > As you can see, it's not much different from the Android.mk itself,
> > only the variable names changes.
> 
> If this is all there is to using androgenizer, I suspect it will stay
> working for longer than the custom Android.mks.  Our experience in Mesa
> has been that basically any time anybody touches the build system for
> anything but a file addition, android gets broken.  By using
> androgenizer, hopefully we rely on a tool that reflects the upstream
> build system better in android, and maybe over time that tool can be
> improved so that android building of upstream projects is less of a
> burden (seriously, why should you have to manually name the sources and
> flags variables?).

Some of the benefits of androgenizer are, that it filters the
contents of the automake variables you pass to it, so you don't
have to manually write only slightly different things in
Android-specific files. As you saw, some Android specific code is
still needed in the build system:

- to pass the automake variables to androgenizer, which cannot
  parse automake files itself. This way we let GNU Make parse the
  automake files, and androgenizer gets the final values.

- a top-level hand-written Android.mk that will execute ./configure
  and everything related, and cause the androgenizer-generated
  Android.mk files to be created. We have managed to create such
  makefiles, that these steps get executed automatically as needed
  during the full Android system build. Whenever new makefiles are
  being generated, GNU Make notices that, and automatically
  restarts the whole build to read them in. (This is not about
  androgenizer but Android builds in general.)

Androgenizer also fixes up all the file paths to be relative to the
Android build root dir, so you don't have to mess with generating
file lists with different path prefixes for automake vs. Android
builds.

Or at least that is what androgenizer should do, it may have bugs
of course. Androgenizer is no magic tool that automatically makes
an autotools project building for Android, but it should help with
the most common pains.

I have some patches in Androgenizer, and I have androgenized few
projects for Collabora. I'd be happy to answer questions about
androgenizer. Please, use my work email (cc'd): ppaalanen at gmail.com


Thanks,
pq