On Wed, Feb 6, 2013 at 12:27 AM, Tom Gall <[email protected]> wrote:
> On Tue, Feb 5, 2013 at 3:32 PM, Chad Versace > <[email protected]> wrote: > > On 02/02/2013 07:33 AM, Tom Gall wrote: > >> On Sat, Feb 2, 2013 at 12:02 AM, Eric Anholt <[email protected]> wrote: > >>> Tom Gall <[email protected]> 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
_______________________________________________ Piglit mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/piglit
