[PATCH 0/3] Android support

[Eric Anholt]

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?).

That said, doesn't the use of _SOURCES in the LIBDRM_SOURCES variable
result in complaints from automake?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121012/ff64ec2c/attachment.pgp>