Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
On Son, 2011-08-07 at 13:14 +0900, Chia-I Wu wrote: 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: 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. Will a single set of Android.mk files work for all potentially relevant Android trees? 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. That would be awesome. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
On 08/07/2011 02:25 AM, Jose Fonseca wrote: - Original Message - 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: 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. Personally, I wouldn't object having the Android.mk on master branch. IMO code should be useful, above being beautiful and clean. As long it is maintained, serves a purpose, and does not impair the current stuff, then it's fine by me FWIW. Jose Having considered this more, I see two large benefits from having the Android.mk's on the master branch. 1) It would relieve Android Mesa maintainers (including me) from the need to periodically rebase the Android branch atop master. 2) More importantly, it would enable anyone working on Android Mesa to simply pull from master and to be able to build and test with all the latest bits. I think (2) is a strong point for keeping the Android.mk's on master. Since the Android port will now be undergoing active development, I believe the inability to simply pull from master and then build and test with the latest bits is a significant, and unnecessary, hindrance to Android GL development. Since Jose is ok with presence of the Android.mk's and no one has posted any vehement objections, I will begin moving forward with this. (This patch series is annoyingly long, and some patches have bugs, so, as time permits, I will repost the series as several smaller, more digestable series of 3 to 4 patches each. I'm at SIGGRAPH this week, so expect the emails to be intermittent.) -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
- Original Message - 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: 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. Personally, I wouldn't object having the Android.mk on master branch. IMO code should be useful, above being beautiful and clean. As long it is maintained, serves a purpose, and does not impair the current stuff, then it's fine by me FWIW. Jose ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
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
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
- 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
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.
!!
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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
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? 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
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. 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 c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
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 diff --git a/Android.mk b/Android.mk new file mode 100644 index 000..4158194 --- /dev/null +++ b/Android.mk @@ -0,0 +1,66 @@ +# +# Copyright © 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the Software), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING +# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER +# DEALINGS IN THE SOFTWARE. +# + +ifneq ($(TARGET_SIMULATOR),true) + +LOCAL_PATH := $(call my-dir) + +# Top directory of Mesa project. +MESA_TOP := $(LOCAL_PATH) + +MESA_PLATFORM := android + +# Each Android.mk must include MESA_LOCAL_VARS before building any targets. +MESA_LOCAL_VARS := $(LOCAL_PATH)/android/mesa_local_vars.mk + +MESA_COMMON_C_INCLUDES := \ + $(MESA_TOP)/include \ + $(MESA_TOP)/src + +MESA_COMMON_CFLAGS := \ + -std=c99 \ + \ + -Wall \ + -Wmissing-prototypes \ + -Wno-sign-compare \ + -Wno-sign-compare \ + \ + -ffast-math\ + -fvisibility=hidden\ + \ + -DFEATURE_ES1 \ + -DFEATURE_ES2 \ + -D_GNU_SOURCE \ + -DHAVE_POSIX_MEMALIGN \ + -DPTHREADS \ + -DTEXTURE_FLOAT_ENABLED\ + -DUSE_X86_ASM + +MESA_COMMON_CPPFLAGS := \ + -Wno-error=non-virtual-dtor \ + -Wno-non-virtual-dtor + +MESA_PYTHON2 := python2 +MESA_PYTHON_FLAGS := -OO -tt + +endif # !TARGET_SIMULATOR diff --git a/android/mesa_local_vars.mk b/android/mesa_local_vars.mk new file mode 100644 index 000..2f8abde --- /dev/null +++ b/android/mesa_local_vars.mk @@ -0,0 +1,32 @@ +# +# Copyright © 2011 Intel Corporation +# +# Permission is hereby granted, free of charge, to any person obtaining a +# copy of this software and associated documentation files (the Software), +# to deal in the Software without restriction, including without limitation +# the rights to use, copy, modify, merge, publish, distribute, sublicense, +# and/or sell copies of the Software, and to permit persons to whom the +# Software is furnished to do so, subject to the following conditions: +# +# The above copyright notice and this permission notice (including the next +# paragraph) shall be included in all copies or substantial portions of the +# Software. +# +# THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +# IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL +# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
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? -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
- 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 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
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/ 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. 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. -- Chad Versace c...@chad-versace.us signature.asc Description: OpenPGP digital signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
