On Fri, 12 Oct 2012 15:27:27 -0700 Eric Anholt <eric@xxxxxxxxxx> wrote: > Negreanu Marius <groleo@xxxxxxxxx> writes: > > > On Thu, Oct 11, 2012 at 12:39 PM, Tapani Pälli <tapani.palli@xxxxxxxxx> 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@xxxxxxxxx Thanks, pq _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
