[Piglit] [PATCH 0/7] RFC: Add Android Support via Android.mk

[Negreanu, Adrian M]

On Wed, Feb 6, 2013 at 12:27 AM, Tom Gall <tom.gall at linaro.org> wrote:

> On Tue, Feb 5, 2013 at 3:32 PM, Chad Versace
> <chad.versace at linux.intel.com> wrote:
> > On 02/02/2013 07:33 AM, Tom Gall wrote:
> >> On Sat, Feb 2, 2013 at 12:02 AM, Eric Anholt <eric at anholt.net> wrote:
> >>> Tom Gall <tom.gall at linaro.org> writes:
> >>>
> >>>> This patch series builds piglit within the Android source tree. It's
> >>>> still a bit of a work in progress but the build succeeds and the tests
> >>>> that are built do pass.
> >>>>
> >>>> The 3rd patch is entirely written by Adrian M Negreanu and really is
> >>>> the heart of the Android implementation for piglit as it adds the
> >>>> framework support without which nothing would work.
> >>>>
> >>>> If anything these patches that create the various Android.mk files are
> >>>> but the strings that hold together Adrian's bouquet. They allow for
> >>>> piglit to build as part of an Android image build which is quite handy
> >>>> for validation farms and such.
> >>>>
> >>>> While this patch series uses multiple Android.mk files, one could
> >>>> implement all of this is one large Android.mk at the top level
> >>>> directory.
> >>>
> >>> Instead of cooking up a brand new build system that will always be
> >>> terribly maintained, it looks like there are a number of
> >>> cmake-for-android projects out there.  Have you exhausted all of those
> >>> as possibilities for sure?
> >>
> >> I entirely understand your concern. I understand that having two build
> >> systems around can be viewed as being less than ideal. I did not take
> >> this step lightly nor was it a thought influenced by appreciation of
> >> one build system over the other.
> >>
> >> Consider:
> >>
> >> Within AOSP the projects that utilize cmake don't use it for Android,
> >> rather they use the Android build system. llvm, libpng, sysbench,
> >> jpeg, clang, libbcc as a for instance.
> >>
> >> Waffle uses the Android build system.
> >>
> >> Mesa uses the Android build system.
> >>
> >> Those coming from the world of Android when contributing know the
> >> Android build system so there is a talent pool. Likewise when working
> >> with Android, you have to know the Android build system.
> >>
> >> When building piglit (&waffle) for Android, one will always have to be
> >> in the presence of the whole android setup with certain portions of
> >> that source tree already built in order for it to work.
> >>
> >> I (or one of my team) can/will happily maintain this. Piglit is very
> >> important to us long term on both Android and Linux.
> >
> >
> > I'm afraid that if we have truly separate build systems for Piglit, then
> > one build will frequently be broken. Very frequently. It's a maintenance
> burden
> > that I would like to avoid.
>
> Thing is. Regardless of cmake or Android.mk, it's going to take those
> interested in Android to keep an eye on Android anyway. It's like
> GLES. I seem to be one of the few people that notices changes which
> are problematic there.
>
> > I'm hoping that there exists a solution that adds only a toplevel
> Android.mk
> > to Piglit, and the Android.mk simply invokes CMake and then calls make. I
> > expect that, using Adrian's patches from Nov 16, it is possible to do
> this.
> > Adrian's patches add the necessary cmake files to inform cmake how to use
> > the Android toolchain; all that is lacking is the toplevel Android.mk
> that
> > calls into cmake.
>
> Well Adrian's patches were able to build, they weren't creating
> non-intel Android binaries. I do need to pull a fresh set. I know he's
> made changes last I gave those a whirl.
>
I added fixes that were needed for arm toolchain, namely the lack
stack-protection library
and also fixed the ccache integration.

Can these two worlds be knitted together? Anything is possible. The
> puzzle is how to get cmake to not only use the android toolchain, but
> also how to get it correctly interpret the env that lunch puts
> together as well as correctly install.

In cmake/Modules/Compiler/Android.cmake there's the get_build_var macro,
that imports Android makefile variables, like TARGET_CC or
TARGET_GLOBAL_LDFLAGS.
This is different from android-cmake in that it doesn't replicate the logic
found in build/core/*.mk.
Also, on the install side, I noticed José Fonseca patches adding install
functionality. I think that can be
integrated with $ANDROID_PRODUCT_OUT.


All of that is certainly
> solvable. It just seems that it is likely to be quite the hack and
> it's the maintaining of that hack that worries me. Given the choice of
> a set of Android.mks that the Android types use or a hack that only we
> piglit types grok is not a fun choice but we must have consensus.
>
> Toward that end I am willing to work together on a prototype
> Android.mk - cmake bridge between what Adrian has done and what I've
> done just to give us all a reference point. Who knows perhaps it'll be
> perfectly acceptable to all, or at least serve as a data point.
>
> Don't suppose between Adrian, Chad, Eric, myself and others
> interested, that some of this merry band might be at ELC here in a
> couple weeks? This might be a good mini-bof over beverages.
>
> > Maybe I'm hoping for something that's impossible. And if it's impossible
> > we should figure out a way to make it un-impossible.
>
> Nothing is impossible. It's all 1s and 0s.
>
> --
> Regards,
> Tom
>
> "Where's the kaboom!? There was supposed to be an earth-shattering
> kaboom!" Marvin Martian
> Tech Lead, Graphics Working Group | Linaro.org │ Open source software
> for ARM SoCs
> w) tom.gall att linaro.org
> h) tom_gall att mac.com
>



-- 
Adrian Marius Negreanu
Intel Open Source Technology Center
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/piglit/attachments/20130206/7b1a0989/attachment.html>