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

[Emil Velikov]

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 ?

> 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.

>>>> but I'm not
>>>> 100% convinced it's any better than specifying them in the mesa ebuild
>>>> (knowing that mesa is the only package we build this way, the
>>>> dependencies are prebuilts that we pull from Android builders).
>>>>
>>> Is adding such workarounds encouranged/wide spread in the ebuild ?
>>> Last time I've looked at the Gentoo ones, there weren't many such
>>> cases.
>>
>> No, it's not usual, at all. The issue here is that we have a chroot
>> that is meant to be a "normal" Linux (that is, Chromium OS), for which
>> we build all the libraries. But, in the same chroot, we also switch to
>> a different toolchain and vastly different system (Android), using
>> prebuilt libraries, to build the second copy of mesa. I guess we are
>> bound to have a number of hacks...
>
> Well, yeah, this is a bit of a special case. I'm planning to improve
> the state of things a bit, though, because we're not yet using all the
> portage functionality that could be useful for this.
>
Indeed. Having a look at the (well placed) FIXME's in the ebuild, I
fully agree with all of them.

>>
>>>> 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) ?


Regards,
Emil