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

[Jose Fonseca]

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

!!

I know that recursive make is considered evil by many, but reading all those make includes can't be fast...

> [1] http://android.git.kernel.org/
> 
> Given this unified design of the Android source tree and build
> process, it
> requires system components, such as Mesa, to be integrated into its
> build
> system. If Mesa is going to support Android, the Android.mk's are
> necessary.

Fair enough.
 
> To address another concern of Dan's, this will not add another way to
> configure
> the Mesa build. Android handles the system's build configuration in a
> single
> location which is outside of Mesa.
> 
> I'm aware that the extra set of makefiles is unwelcome, but their
> presence will
> be innocuous. The only people that will need to touch them are those
> maintaining
> the Android build.

The most command kind of change to build system is by far adding/removing/renaming source files, which currently have to be replicated on each.

Developers typically use only one build system, so it is natural to forget/ignore updating all, which breaking builds, loosing benefit of continuous testing, and makeing difficult to bisect in the future.

Spite different build systems, we could try unifying the source lists (have a .mk which is read by all build systems, including scons) and/or automate source lists (have one target per dir, and simply glob all *.{c,h,cpp,hpp}).

Jose