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

[Tomasz Figa]

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?

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.

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.

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

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

Best regards,
Tomasz