[Mesa-dev] [PATCH 1/2] configure.ac: Add support for Android builds

[Tomasz Figa]

Uhm, dropped other recipients by mistake last time. As I said, it was
too late hour to reply for me. :)

On Sun, May 29, 2016 at 2:09 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 27 May 2016 at 17:22, Tomasz Figa <tfiga at chromium.org> wrote:
>> On Sat, May 28, 2016 at 12:48 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>> Hello gents,
>>>
>>> On 27 May 2016 at 12:33, Tomasz Figa <tfiga at chromium.org> wrote:
>>>> Hi,
>>>>
>>>> On Fri, May 27, 2016 at 7:36 PM, Nicolas Boichat <drinkcat at chromium.org> wrote:
>>>>> Hi Emil,
>>>>>
>>>>> Took us some time to clean things up, but we got an ebuild and repo to
>>>>> share with you.
>>>>>
>>>>> On Tue, May 24, 2016 at 10:52 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>>> [snip]
>>>>>>> We also set PKGCONFIG="false", because, well, we do not have .pc files
>>>>>>> for Android libs. We _could_ create them manually, though,
>>>>>> Arr... it seems like there's more 'hacks' then expected. I would
>>>>>> kindly urge that if you're using the autoconf build to use .pc files,
>>>>>> please ?
>>>>>>
>>>>>> There's not need to manually create any of them - just throw the
>>>>>> template and wire it up in the build system.
>>>>>
>>>>> Not quite sure how that'd work out, I guess I'll see ,-)
>>>>>
>>>>
>>>> I'd also vote for using .pc files for the non-Android dependencies,
>>>> but I'm not sure how we could use them for Android ones. Do you mean
>>>> hacking up something like android_egl.pc that would include all the
>>>> necessary Android libraries for the EGL platform module?
>>>>
>>> Ideally there'll be a separate .pc for each required library/module.
>>>
>>>> One more thing to note is that this series is an attempt to make it
>>>> possible to build Mesa for Android externally, without the need to
>>>> maintain a whole alternative set of makefiles or other redundant
>>>> entities. So I think we shouldn't go to extremes and now the users of
>>>> this create yet another type of such objects for Android side of
>>>  > things (.pc files), if it could just stay there in the source tree,
>>>> unlikely to require changes in any near future.
>>>>
>>> /me scratches head and attempts to parse two consecutive 4 line sentences.
>>> Can you please rephrase the above ?
>>
>> Can't even parse it myself now, I guess too late hour to write emails for me.
>>
>> I believe I meant that this series attempts to reduce the number of
>> extra files needed to build Mesa for Android, so asking the user (the
>> person building) to create more of them (pc for Android libs) would be
>> IMHO a bit contradictory.
>>
> That's why I proposed to create them ;-) If anyone else wants to
> rebuild mesa in a similar way they are bound to use AOSP {,based}
> packages - libhardware... thus once things are in, there'll be no
> overhead/drawback for anyone.
>
>>>
>>>> One alternative for the two mentioned solutions would be just letting
>>>> the user specify the list of Android libraries to include using
>>>> environment variables, without involving pkgconfig into this at all.
>>>> This way we would neither have to create .pc files for Android
>>>> libraries nor hardcode specific library names into Makefile.am.
>>>>
>>> That's an option indeed. Sadly the the easiest way to butcher
>>> things... as in one will get things right eventually, but the time
>>> spent debugging/asking around will be far greater than hacking 2-3 .pc
>>> files.
>>
>> Hmm, let me make sure that I have a correct understanding.
>>
>> So with the setup you're suggesting we would have pkgconfig modules
>> for libhardware, libcutils and libsync. Then from Makefile.am we would
>> dereference the respective _CFLAGS and _LIBS variables.
> Yes. It would be really good if we can have that.
>
>> So, if I got
>> this right, it would mean hardcoding indirectly the dependencies for
>> certain Android libs in Makefile.am. How is this different from simply
>> adding "-lhardware -lcutils -lsync" there?
>>
> As a counter argument why does anyone bothers with .pc (and equivalent
> cmake) files ;-)
>
> Let me try to break down and answer your (personally or as a team) concerns:
>  - Who will create the said files ?
> If you guys don't have time/interest I can do that ;-)
>  - Why bother since we can hardcode it in the ebuild.
> Yes, but one might want to build it via another method - yocto,
> buildroot, rpms (.spec files) ... Thus the said thing will have to be
> copied everywhere and then kept in sync.
>  - It feels strange having .pc files in an AOSP build system.
> Fully agree. Yet it's a very small price (both initial 'investment'
> and maintenance) to pay for a cleaner solution and greater
> portability. On a similar note some (sadly not many) upstream projects
> keep the Android build upstream as a sign of good will towards
> Android.
>
> I get the feeling that each of us, individually, could have written
> the said .pc files in a fraction of the actual discussion.

Yeah, writing is not the thing I was concerned about, but rather where
to put them. But maybe we can indeed manage to include them in AOSP,
to be honest I didn't even think about this.

>
>>>>>
>>>>>>> So we replace them with LIBXYZ_[CFLAGS/LIBS], and configure is happy with that.
>>>>>>>
>>>>>>> One thing that I wonder about is how we could specify
>>>>>>> libEGL_la_LIBADD += -lhardware -lcutils -lsync
>>>>>>> without hardcoding it in the Makefile.am.
>>>>>>>
>>>>>>> Any idea how we could do that? Or do you think it's ok to hardcode the libs?
>>>>>>>
>>>>>> The proposed solution will handle these. If you guys feel that it's
>>>>>> too much/annoying to deal with, show me a repo and I'll send you the
>>>>>> patches ;-) Please ?
>>>>>
>>>>> Alright, so the ebuild is here:
>>>>> https://chromium-review.googlesource.com/#/c/347700/ (if you have a
>>>>> Chromium OS chroot, it should just work).
>>>>>
>>>>> And the patches are here:
>>>>> https://chromium.googlesource.com/chromiumos/third_party/mesa/+log/arc-11.3.0-pre1
>>>>>
>>>>> They are still based on a slightly older version of mesa. Tomasz is
>>>>> working on rebasing to the latest mesa master (it looks like someone
>>>>> implemented similar changes to ours to add support for PRIME FD).
>>>>
>>>> Yeah, we've been building things up on top of the DRI loader
>>>> extension, but now there is equivalent functionality upstream with DRI
>>>> image loader, however somehow it doesn't work for us yet, I'm
>>>> debugging it right now.
>>>>
>>> Some things that come to mind:
>>>  - do you have the render nodes created ?
>>>  - does drmGetNodeTypeFromFd() return the correct value ?
>>>  - does the assumption in get_native_buffer_fd() hold true on your
>>> platform (gralloc implementation) ?
>>>
>>
>> Yeah, we had this stuff running with very similar code before, so
>> these points hold true. I'm getting some NULL pointer dereference in
>> i965_dri.so, but didn't manage to dig into it yet. It's very likely to
>> be related to our own addition rebased on top of new codebase.
>>
> Hmm this reminds me ... one of the Android-x86 guys spotted an issue
> that was triggered with the "use dmabuf/rendernode" patches from Rob
> H. I will forward you his analysis (note he's not at expert in the
> area) in a moment.

Thanks. Will surely be useful for further debugging.

>
> Have you guys, as a team or as a division of Google, considered
> interacting more with the Android-x86 people ? I would imagine that
> there will be benefits on both sides ?

Well, I suppose there will be enough opportunities to interact, since
I intend to upstream the Mesa changes we made. I can't say anything
about non-Chromium projects, unfortunately.