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

[Chia-I Wu]

On Sat, Aug 6, 2011 at 5:07 AM, Chad Versace <chad at chad-versace.us> wrote:
> 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.
I do not have a strong motivation to upstream Android support because

 - it requires changes to Android framework
 - it introduces yet another build system to Mesa

I said this a few months back on mesa-user or -dev when asked.

But generally, I think the not cluttering Mesa with another build
system is debatable.  I know I conflict with myself here, but if
someone ports Mesa to arguably the most widely used OS and would like
to upstream it, should we shut it down because the OS _requires_ its
own build system?  Incidentally, gstreamer has Android.mk upstream.
> 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.
Yes, that surely will make the out-of-tree port be more future proof.
I think we can make SCons parses the source list too.

> (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
>
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/mesa-dev
>
>



-- 
olv at LunarG.com