Hi, Il giorno gio 6 set 2018 alle ore 18:20 Dylan Baker <dy...@pnwbakers.com> ha scritto: > > Quoting Rob Herring (2018-09-06 07:16:07) > > On Mon, Sep 3, 2018 at 4:27 PM Eric Anholt <e...@anholt.net> wrote: > > > > > > Mauro Rossi <issor.or...@gmail.com> writes: > > > > > > > Fixes the following building error, happening when building both intel > > > > and broadcom: > > > > > > I wish someone maintaining android Mesa would work on making the meson > > > build work for them instead of just continuing to maintain the > > > Android.mk mess. > > > > Trust me, no one likes this thankless job. > > > > How do you envision that would work without meson support in the > > Android build system? I went down the path of defining a "prebuilt" > > Android.mk target which calls meson to do a build. This was a dead end > > because the Android.mk gets none of the build environment. It's > > possible to dump all that out and re-construct those settings. That > > seems horribly fragile, and I'd guess we'd just be switching from mesa > > to AOSP breaking the build. Of course the latter already happens too. > > Finally, I'm pretty sure this would not be accepted for the AOSP copy > > of mesa (which is trying to track mainline). > > > > The other route would be some sort automatic meson to Android BP build > > file translation. Such a thing exists for autotools, but I've never > > seen it in actual use anywhere. > > > > Either way, this seems like a unicorn to me until AOSP provides some > > support to support meson. If you really want to force the issue, strip > > all the Android.mk files out of mesa. Though that will mainly put the > > pain on downstream device trees, not AOSP. > > > > Rob > > With my meson hat on, > > I've been looking at blueprint recently, trying to decide if we could > implement > a meson-for-android on top of blueprint. While I know a lot about meson (I've > written a bunch of the meson implementation), I don't know a lot about > blueprint > and their documentation is basically aimed at explaining how soong works. I > certainly can't commit to full time development on a meson-on-blueprint > implementation, but I certainly could help write one if there was someone > interested in working on it as well. It would also be helpful if there was > someone in the blueprint camp who could tell me whether such a thing is even > feasible or not. > > Dylan
I can comment that when talking about the patching process in Mesa, it is very much clear when Android.mk changes are needed and there are many people currently supporting Android.mk and in the last three years there was much attention to keep Android.mk in good shape. That's why it is in good shape. In my understanding kati for building with Android.mk will be dropped at some point, Android.bp will be the only building script language supported by AOSP. Android.bp will be easier to mantain than Android.mk, because Android.bp is intentionally very similar to Bazel build script language, which should have corresponding objects and grammar/syntax rules than can be translated or visually inspected, if people will continue to care. IMHO .go language scripts should not be used when unnecessary, for architecture conditionals and genrules that may be supported in Android.bp but environement variables, if I understood correctly, will require .go script because of how Blueprint is inspired to Bazel but not identical. I'm still wondering if a .go-less Android.bp may be feasible So options are: 1. Use the androidmk parser / blueprint_tools to perform the draft translation, then huge work to fix the Android.bp build through all the tree. 2. meson to Android.bp parser/translator - this would be interesting, if we could find a way to generate the .go which is not tackled with in 1.,or surrogate rules in bp 3. Go to Google ninja-build forums if they have plans to perform feasibility analysis and develop soong to accept meson directly (In the long term it is a Win for them) 4. Go to Google Build forum and propose a meson-to-bp added to blueprint_tools (and have part of this task driven by them - A clearly mesa is not the only project using meson) 5. Propose Google to setup one/two projects for next GSoC in area 3. and 4. 6. Wait for Google be at the milestone of kati/Android.mk demise and see how they will build mesa. I am interested in contributing in part of my spare time. Mauro _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
