-devel at lists.freedesktop.org
>> Subject: Re: [PATCH 0/8] Upstreaming the Android build and misc fixes
>>
>> On Mon, Jul 28, 2014 at 01:01:19PM +0100, Emil Velikov wrote:
>>> On 28/07/14 08:07, Daniel Vetter wrote:
>>>> On Mon, Jul 28, 2014 at 03:48:53AM
Hi Emil, these seemed to work ok, with two fixes.
1) Patch 3 didn't apply cleanly to the master branch due to a difference in the
Author email address for a couple of files.
2) The Android.mk at the top level, at the end where you include the sub
makefiles,
You need to use LIBDRM_TOP instead o
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch] On Behalf Of Daniel
> Vetter
> Sent: Monday, July 28, 2014 4:22 PM
> To: Emil Velikov
> Cc: Daniel Vetter; Gore, Tim; dri-devel at lists.freedesktop.org
> Subject: Re: [PATCH 0/8] Upstream
On Mon, Jul 28, 2014 at 01:01:19PM +0100, Emil Velikov wrote:
> On 28/07/14 08:07, Daniel Vetter wrote:
> > On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote:
> >> A few updates:
> >>
> >> - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed
> >> to
> >> *_H_FILES
>
On 28/07/14 08:07, Daniel Vetter wrote:
> On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote:
>> A few updates:
>>
>> - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to
>> *_H_FILES
>> - Including the platform Android.mk files individually is not the right way
>
On Mon, Jul 28, 2014 at 03:48:53AM +0100, Emil Velikov wrote:
> A few updates:
>
> - Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to
> *_H_FILES
> - Including the platform Android.mk files individually is not the right way
> to do. One needs to construct an array/list of
A few updates:
- Naming the headers lists *_HEADERS caused autohell to hate us. Renamed to
*_H_FILES
- Including the platform Android.mk files individually is not the right way
to do. One needs to construct an array/list of Android.mks and include it.
- The series including the above fixes can
Hello list,
Recently I've had a go at the Anroid builds and I felt ... inspired that
there are (at least) two downstream repositories that have the relevant
Android build, yet all of them use 6+month old libdrm.
Making even builds a pain in the neck :'(
Are there any objections if we get the andr