<div dir="ltr"><div class="gmail_extra">On Wed, Feb 6, 2013 at 12:27 AM, Tom Gall <span dir="ltr"><<a href="mailto:tom.gall@linaro.org" target="_blank">tom.gall@linaro.org</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Tue, Feb 5, 2013 at 3:32 PM, Chad Versace<br>

<<a href="mailto:chad.versace@linux.intel.com">chad.versace@linux.intel.com</a>> wrote:<br>
> On 02/02/2013 07:33 AM, Tom Gall wrote:<br>
>> On Sat, Feb 2, 2013 at 12:02 AM, Eric Anholt <<a href="mailto:eric@anholt.net">eric@anholt.net</a>> wrote:<br>
>>> Tom Gall <<a href="mailto:tom.gall@linaro.org">tom.gall@linaro.org</a>> writes:<br>
>>><br>
>>>> This patch series builds piglit within the Android source tree. It's<br>
>>>> still a bit of a work in progress but the build succeeds and the tests<br>
>>>> that are built do pass.<br>
>>>><br>
>>>> The 3rd patch is entirely written by Adrian M Negreanu and really is<br>
>>>> the heart of the Android implementation for piglit as it adds the<br>
>>>> framework support without which nothing would work.<br>
>>>><br>
>>>> If anything these patches that create the various Android.mk files are<br>
>>>> but the strings that hold together Adrian's bouquet. They allow for<br>
>>>> piglit to build as part of an Android image build which is quite handy<br>
>>>> for validation farms and such.<br>
>>>><br>
>>>> While this patch series uses multiple Android.mk files, one could<br>
>>>> implement all of this is one large Android.mk at the top level<br>
>>>> directory.<br>
>>><br>
>>> Instead of cooking up a brand new build system that will always be<br>
>>> terribly maintained, it looks like there are a number of<br>
>>> cmake-for-android projects out there.  Have you exhausted all of those<br>
>>> as possibilities for sure?<br>
>><br>
>> I entirely understand your concern. I understand that having two build<br>
>> systems around can be viewed as being less than ideal. I did not take<br>
>> this step lightly nor was it a thought influenced by appreciation of<br>
>> one build system over the other.<br>
>><br>
>> Consider:<br>
>><br>
>> Within AOSP the projects that utilize cmake don't use it for Android,<br>
>> rather they use the Android build system. llvm, libpng, sysbench,<br>
>> jpeg, clang, libbcc as a for instance.<br>
>><br>
>> Waffle uses the Android build system.<br>
>><br>
>> Mesa uses the Android build system.<br>
>><br>
>> Those coming from the world of Android when contributing know the<br>
>> Android build system so there is a talent pool. Likewise when working<br>
>> with Android, you have to know the Android build system.<br>
>><br>
>> When building piglit (&waffle) for Android, one will always have to be<br>
>> in the presence of the whole android setup with certain portions of<br>
>> that source tree already built in order for it to work.<br>
>><br>
>> I (or one of my team) can/will happily maintain this. Piglit is very<br>
>> important to us long term on both Android and Linux.<br>
><br>
><br>
> I'm afraid that if we have truly separate build systems for Piglit, then<br>
> one build will frequently be broken. Very frequently. It's a maintenance burden<br>
> that I would like to avoid.<br>
<br>
</div></div>Thing is. Regardless of cmake or Android.mk, it's going to take those<br>
interested in Android to keep an eye on Android anyway. It's like<br>
GLES. I seem to be one of the few people that notices changes which<br>
are problematic there.<br>
<div class="im"><br>
> I'm hoping that there exists a solution that adds only a toplevel Android.mk<br>
> to Piglit, and the Android.mk simply invokes CMake and then calls make. I<br>
> expect that, using Adrian's patches from Nov 16, it is possible to do this.<br>
> Adrian's patches add the necessary cmake files to inform cmake how to use<br>
> the Android toolchain; all that is lacking is the toplevel Android.mk that<br>
> calls into cmake.<br>
<br>
</div>Well Adrian's patches were able to build, they weren't creating<br>
non-intel Android binaries. I do need to pull a fresh set. I know he's<br>
made changes last I gave those a whirl.<br></blockquote><div>I added fixes that were needed for arm toolchain, namely the lack stack-protection library</div>and also fixed the ccache integration.</div><div class="gmail_quote">
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Can these two worlds be knitted together? Anything is possible. The<br>
puzzle is how to get cmake to not only use the android toolchain, but<br>
also how to get it correctly interpret the env that lunch puts<br>
together as well as correctly install.</blockquote><div>In cmake/Modules/Compiler/Android.cmake there's the get_build_var macro,</div>that imports Android makefile variables, like TARGET_CC or TARGET_GLOBAL_LDFLAGS.</div>
<div class="gmail_quote" style>This is different from android-cmake in that it doesn't replicate the logic found in build/core/*.mk.</div><div class="gmail_quote" style>Also, on the install side, I noticed José Fonseca patches adding install functionality. I think that can be</div>
<div class="gmail_quote" style>integrated with $ANDROID_PRODUCT_OUT.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
 All of that is certainly<br>
solvable. It just seems that it is likely to be quite the hack and<br>
it's the maintaining of that hack that worries me. Given the choice of<br>
a set of Android.mks that the Android types use or a hack that only we<br>
piglit types grok is not a fun choice but we must have consensus.<br>
<br>
Toward that end I am willing to work together on a prototype<br>
Android.mk - cmake bridge between what Adrian has done and what I've<br>
done just to give us all a reference point. Who knows perhaps it'll be<br>
perfectly acceptable to all, or at least serve as a data point.<br>
<br>
Don't suppose between Adrian, Chad, Eric, myself and others<br>
interested, that some of this merry band might be at ELC here in a<br>
couple weeks? This might be a good mini-bof over beverages.<br>
<div class="im"><br>
> Maybe I'm hoping for something that's impossible. And if it's impossible<br>
</div><div class="im">> we should figure out a way to make it un-impossible.<br>
<br>
</div>Nothing is impossible. It's all 1s and 0s.<br>
<br>
--<br>
Regards,<br>
Tom<br>
<br>
"Where's the kaboom!? There was supposed to be an earth-shattering<br>
kaboom!" Marvin Martian<br>
Tech Lead, Graphics Working Group | Linaro.org │ Open source software<br>
for ARM SoCs<br>
w) tom.gall att <a href="http://linaro.org" target="_blank">linaro.org</a><br>
h) tom_gall att <a href="http://mac.com" target="_blank">mac.com</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Adrian Marius Negreanu</div><div>Intel Open Source Technology Center <div><div><br></div><p></p></div></div>
</div></div>