Negreanu Marius groleo@gmail.com writes:
On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli tapani.palli@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?