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

[Tom Gall]

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.

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