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

[Mauro Rossi]

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