On Sat, Aug 6, 2011 at 5:07 AM, Chad Versace <c...@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 <c...@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 <c...@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 <o...@lunarg.com>, >>>>>> CC: Chih-Wei Huang <cwhu...@android-x86.org> >>>>>> Signed-off-by: Chad Versace <c...@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 > c...@chad-versace.us > > > _______________________________________________ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > > -- o...@lunarg.com _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev