[Mesa-stable] [PATCH 1/3] android: broadcom/genxml: fix collision with intel/genxml header-gen macro

[Dylan Baker]

Quoting Mauro Rossi (2018-09-09 01:56:20)
> Hi,
> 
> Il giorno gio 6 set 2018 alle ore 18:20 Dylan Baker
> <dylan at pnwbakers.com> ha scritto:
> >
> > Quoting Rob Herring (2018-09-06 07:16:07)
> > > On Mon, Sep 3, 2018 at 4:27 PM Eric Anholt <eric at anholt.net> wrote:
> > > >
> > > > Mauro Rossi <issor.oruam at 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

I think those are basically the options we have, along with my suggestion to
write a go module that can parse meson at build time, which blueprint supports.
For us it would be a huge win if Google would support meson in some form, since
that would allow us to get down to just one build system for the graphics (minus
kernel which Google has to figure out anyway) ecosystem. That's a huge win for
mesa, libdrm, etc.

Dylan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: signature
URL: <https://lists.freedesktop.org/archives/mesa-stable/attachments/20180910/6d79b4d6/attachment.sig>