[Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk

Chad Versace chad at chad-versace.us
Fri Aug 5 13:07:16 PDT 2011


On 08/05/2011 05:41 AM, Dan Nicholson wrote:
> On Thu, Aug 4, 2011 at 7:55 PM, Chad Versace <chad at chad-versace.us> wrote:
>> On 08/04/2011 04:17 PM, Jose Fonseca wrote:
>>> ----- Original Message -----
>>>> On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace <chad at chad-versace.us>
>>>> wrote:
>>>>> This is the first step in porting libGLES* and libEGL to Android.
>>>>>
>>>>> The makefile doesn't build anything yet; it just defines common
>>>>> variables.
>>>>>
>>>>> The values for MESA_COMMON_C_FLAGS and MESA_COMMON_CPP_FLAGS, I
>>>>> obtained
>>>>> by invoking autogen.sh with the options below and then inspecting
>>>>> MESA_TOP/configs/autoconf. My immediate goal is to port i965 to
>>>>> Android,
>>>>> so I used the typical flags for building i965.
>>>>>    --disable-gallium
>>>>>    --disable-glu
>>>>>    --disable-glw
>>>>>    --disable-glut
>>>>>    --enable-32-bit
>>>>>    --enable-egl
>>>>>    --enable-gles2
>>>>>    --enable-gles1
>>>>>    --enable-texture-float
>>>>>    --with-dri-drivers=i965
>>>>>    --with-gallium-drivers=
>>>>>
>>>>> Note: This is in preparation for porting i965 to Android.
>>>>> CC: Chia-I Wu <olv at lunarg.com>,
>>>>> CC: Chih-Wei Huang <cwhuang at android-x86.org>
>>>>> Signed-off-by: Chad Versace <chad at chad-versace.us>
>>>>> ---
>>>>>  Android.mk                 |   66
>>>>>  ++++++++++++++++++++++++++++++++++++++++++++
>>>>>  android/mesa_local_vars.mk |   32 +++++++++++++++++++++
>>>>>  2 files changed, 98 insertions(+), 0 deletions(-)
>>>>>  create mode 100644 Android.mk
>>>>>  create mode 100644 android/mesa_local_vars.mk
>>>>
>>>> There's quite a bit of new build infrastructure here. What would it
>>>> take to fit this into either the existing autoconf support or add a
>>>> targeted configs/android? Duplicating a pile of make targets and
>>>> adding another way to configure/build mesa seems like it might not be
>>>> the best way to go. What are the current constraints that make
>>>> building mesa on android difficult?
>>>
>>> I agree. I'd prefer not have yet another build infrastructure in the mix, unless there's a very good reason.
>>>
>>> Jose
>>
>> I also agree. I would prefer to not add another build system to Mesa. We have
>> too many as it is.
>>
>> To address Dan's questions, the Android build cannot be fitted into autoconf or
>> configs/android. I explored this option, and discovered that it was impossible.
>> The Android build system is... well... interesting. Allow me to explain.
>>
>> The entirety of the Android project --- libc, webkit, the window manager,
>> *everything* --- exists in a single source tree [1]. And that source tree is
>> built with a single, non-recursive invocation of make. Every time I say that, I
>> find it hard to believe myself, so I'll say it again: The entirety of the
>> Android OS, all core libraries and apps, are built with a single, non-recursive
>> invocation of make. (The kernel is the special exception to this
>> all-encompassing build). The final build artifact is a bootable iso image.
>>
>> [1] http://android.git.kernel.org/
> 
> Looking at all those git repos, wouldn't this be more appropriate as
> an android project? platform/external/mesa or something?

Mesa already belongs to the Android x86 tree [1] as platform/external/mesa. (The
Android x86 project is a fork that closely mirrors upstream Android). It also
exists as such in some private trees.

[1] http://git.android-x86.org/

> I haven't
> seen any Android.mk files show up in freetype or expat or anything
> like that. In the same way, mesa doesn't carry a debian folder even
> though that's how debian and ubuntu build mesa. Certainly if there are
> fixes to the existing build infrastructure that help get mesa built on
> android, that should be done, but I don't see why we should carry the
> android build bits in upstream mesa.
> 
> --
> Dan

Dan, you make a strong point. There's no sense in cluttering Mesa with
additional makefiles, at least not now. Other projects do not do that for
Android, and Mesa doesn't even do it for beloved Debian. The best approach would
be to maintain the Android makefiles in a separate branch, perhaps even in a
personal repo.

To fix the existing build infrastructure to support Android, I would like to
extract source lists for some targets into a shared makefile, similiar to what
has been done with src/mesa/sources.mak. Jose suggested this, and I think this
is the best way to continue.

(Jose, I would rather not take the approach of making one target per directory
and using glob patters to pick up the source files. I expect conflicts to occur
between Gallium and non-Gallium drivers.)

-- 
Chad Versace
chad at chad-versace.us

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20110805/9438c8d9/attachment.pgp>


More information about the mesa-dev mailing list