Hello gents, On 27 May 2016 at 12:33, Tomasz Figa <tf...@chromium.org> wrote: > Hi, > > On Fri, May 27, 2016 at 7:36 PM, Nicolas Boichat <drink...@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.veli...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
