Re: [Mesa-dev] [PATCH] configure.ac: Disable GLX if OpenGL is not enabled
On Jan 31, 2013 2:51 AM, Michel Dänzer mic...@daenzer.net wrote: From: Michel Dänzer michel.daen...@amd.com GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL. Signed-off-by: Michel Dänzer michel.daen...@amd.com --- configure.ac |8 1 file changed, 8 insertions(+) diff --git a/configure.ac b/configure.ac index cfd52bf..62cc32b 100644 --- a/configure.ac +++ b/configure.ac @@ -701,6 +701,14 @@ if test x$enable_dri$enable_xlib_glx = xyesyes; then AC_MSG_ERROR([DRI and Xlib-GLX cannot be built together]) fi +# Disable GLX if OpenGL is not enabled +if test x$enable_glx = xyes -a \ +x$enable_opengl = xno; then +AC_MSG_WARN([OpenGL not enabled, disabling GLX]) +enable_glx=no +enable_xlib_glx=no +fi Seems correct. I might prefer this to error, but warn is probably good enough. The option to disable opengl didn't exist back when these checks were written. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Save user {C, CXX}FLAGS and append them at end.
On Mon, Dec 31, 2012 at 6:03 AM, Dan Nicholson dbn.li...@gmail.com wrote: On Sun, Dec 23, 2012 at 3:41 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Am Samstag, 22. Dezember 2012, 16:34:48 schrieben Sie: On Sat, Dec 22, 2012 at 10:47 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Am Samstag, 22. Dezember 2012, 09:21:33 schrieb Matt Turner: On Sat, Dec 22, 2012 at 9:16 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: This way the user has the privilege of last decision and so the option to build an optimized debug build again. --- You can just do CFLAGS=-g -O2 ./configure can't you? Nope. CXXFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' CFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' ./autogen.sh --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --enable-xvmc --enable-vdpau --enable-texture-float --enable-debug --with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast --with-gallium-drivers=i915,nouveau,r300,r600,svga,swrast --enable-dri --enable-glx --enable-osmesa --enable-gles1 --enable-gles2 --enable-openvg --enable-shared-glapi --enable-shared-gallium --enable-gbm --enable-xa --ena ble-gallium-egl --enable-gallium-llvm --enable-gallium-gbm --enable-opencl --enable-r600-llvm-compiler --enable-gallium-g3dvl --enable-glx-tls Resulting Makefile: before: CFLAGS = -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O0 after: CFLAGS = -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O0 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g You see configure CFLAGS and initial CFLAGS are vice versa. The real fix here is not to have configure.ac touch CFLAGS at all like any reasonable autotools project. That was an unfortunate shortcut during the initial work. That would be a lot more effort, though. Initial work after ~ 5 years? http://cgit.freedesktop.org/mesa/mesa/commit/?id=122345876479cf5cf553e38162ab105658614ab7 Not sure what you mean by this. When I wrote configure.ac however many years ago, I didn't cleanly split off CFLAGS set by mesa from the user's CFLAGS as a shortcut. Looking back now, I should have just bit the bullet and made something like MESA_CFLAGS/MESA_LDFLAGS and made all the Makefiles use that. Btw: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ff2efdf5997d20b41f7a82b77118366e6fbd23bc http://cgit.freedesktop.org/mesa/mesa/commit/?id=33ae29c93b8f70a86dcedc495dd658a5d5679db3 This patch covers the motivation for commit 33ae29c. However, the typical convention is that the user's CFLAGS come first (see any automake COMPILE or LTCOMPILE definition), mostly so that any user specified -I paths take precedence. That's unfortunate when -O options to gcc are last one wins, but that's how things have typically been. I would make this change very cautiously. -- Dan And here is the real reason for my request: /usr/lib64/mesa-demos/egl/opengl/xeglgears AMD Fusion (fps) Nvidia ION (fps) -O0 -O2 -O0 -O2 562,7 750,778 0,33641,851 921,464 0,44 701,756 662,877 -0,06 693,752 1000,1960,44 571,566 665,052 0,16692,196 936,147 0,35 542,715 664,658 0,22693,733 995,499 0,43 542,935 664,78 0,22692,702 992,634 0,43 542,574 665,398 0,23692,835 998,665 0,44 542,945 663,087 0,22691,353 998,319 0,44 541,732 664,253 0,23656,32 995,91 0,52 543,392 665,078 0,22691,084 994,037 0,44 542,901 663,406 0,22693,464 996,858 0,44 5635,2166729,3670,196839,29 9829,7290,44 (sum) - Performance + 19 % on AMD Fusion, + 44 % on Nvidia ION on debug build with -O2. :-) Usual users should build Mesa with default FLAGS. Advanced users should be able to build it with their own FLAGS without modifying source. Right, --enable-debug is forcing you to have -O0. That's the problem. Mesa should not be overriding user defined flags such as optimization unless it's necessary to get Mesa to build. There are two issues here: 1. Adding -O0
[Mesa-dev] [PATCH 1/2] configure: Keep track of user compiler/linker flags, but don't restore
Since mesa occasionally alters the users's compiler and linker flags, it's useful to keep track of their original settings so the user's intentions are respected. However, since mesa may alter the variables with settings required for the build, they should not be restored to their original settings. Signed-off-by: Dan Nicholson dbn.li...@gmail.com --- configure.ac | 21 + 1 files changed, 9 insertions(+), 12 deletions(-) diff --git a/configure.ac b/configure.ac index 1414ce8..eebfef8 100644 --- a/configure.ac +++ b/configure.ac @@ -17,6 +17,15 @@ dnl http://people.gnome.org/~walters/docs/build-api.txt dnl We don't support srcdir != builddir. echo \#buildapi-variable-no-builddir /dev/null +dnl Keep track of user's compiler/linker flags so we know their original +dnl settings in case we need to alter the variables. +_USER_CFLAGS=$CFLAGS +_USER_CXXFLAGS=$CXXFLAGS +_USER_CFLAGS_FOR_BUILD=$CFLAGS_FOR_BUILD +_USER_CXXFLAGS_FOR_BUILD=$CXXFLAGS_FOR_BUILD +_USER_LDFLAGS=$LDFLAGS +_USER_CPPFLAGS=$CPPFLAGS + # Support silent build rules, requires at least automake-1.11. Disable # by either passing --disable-silent-rules to configure or passing V=1 # to make @@ -153,10 +162,6 @@ dnl LIB_DIR - library basename LIB_DIR=`echo $libdir | $SED 's%.*/%%'` AC_SUBST([LIB_DIR]) -dnl Cache LDFLAGS and CPPFLAGS so we can add to them and restore later -_SAVE_LDFLAGS=$LDFLAGS -_SAVE_CPPFLAGS=$CPPFLAGS - dnl build host compiler macros DEFINES_FOR_BUILD= AC_SUBST([DEFINES_FOR_BUILD]) @@ -1962,14 +1967,6 @@ AM_CONDITIONAL(HAVE_SPARC_ASM, echo $DEFINES | grep 'SPARC_ASM' /dev/null 2 dnl prepend CORE_DIRS to SRC_DIRS SRC_DIRS=$CORE_DIRS $SRC_DIRS -dnl Restore LDFLAGS and CPPFLAGS -LDFLAGS=$_SAVE_LDFLAGS -CPPFLAGS=$_SAVE_CPPFLAGS - -dnl Add user CFLAGS and CXXFLAGS -CFLAGS=$CFLAGS $USER_CFLAGS -CXXFLAGS=$CXXFLAGS $USER_CXXFLAGS - dnl Substitute the config AC_CONFIG_FILES([configs/current Makefile -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH 2/2] configure: Don't override compiler optimization settings when debugging
As a convenience, --enable-debug will add -g -O0 to the compiler flags when GCC is in use. This is helpful but has the drawback that it will override the user's optimization settings. Instead, only add the convenience -g -O0 when the user has not set their compiler flags at all. Signed-off-by: Dan Nicholson dbn.li...@gmail.com --- configure.ac | 10 ++ 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/configure.ac b/configure.ac index eebfef8..bfe551f 100644 --- a/configure.ac +++ b/configure.ac @@ -345,18 +345,20 @@ AC_ARG_ENABLE([debug], ) if test x$enable_debug = xyes; then DEFINES_FOR_BUILD=$DEFINES_FOR_BUILD -DDEBUG -if test x$GCC_FOR_BUILD = xyes; then +if test x$GCC_FOR_BUILD = xyes \ + test x$_USER_CFLAGS_FOR_BUILD = x; then CFLAGS_FOR_BUILD=$CFLAGS_FOR_BUILD -g -O0 fi -if test x$GXX_FOR_BUILD = xyes; then +if test x$GXX_FOR_BUILD = xyes \ + test x$_USER_CXXFLAGS_FOR_BUILD = x; then CXXFLAGS_FOR_BUILD=$CXXFLAGS_FOR_BUILD -g -O0 fi DEFINES=$DEFINES -DDEBUG -if test x$GCC = xyes; then +if test x$GCC = xyes test x$_USER_CFLAGS = x; then CFLAGS=$CFLAGS -g -O0 fi -if test x$GXX = xyes; then +if test x$GXX = xyes test x$_USER_CXXFLAGS = x; then CXXFLAGS=$CXXFLAGS -g -O0 fi fi -- 1.7.7.6 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] glxinfo proposed change
On Mon, Jan 7, 2013 at 5:06 AM, Jorge Ramirez Ortiz, HCL Europe
jorge.ramirez-or...@hcl.com wrote:
Hi all,
Does this patch make sense? glVersion can be NULL and not having the changes
below could cause a SIGSEGV
[jramirez@calypso-2 mesa-demos.git (tmp *)]$ git diff src/xdemos/glxinfo.c
diff --git a/src/xdemos/glxinfo.c b/src/xdemos/glxinfo.c
index aa6430d..97b6539 100644
--- a/src/xdemos/glxinfo.c
+++ b/src/xdemos/glxinfo.c
@@ -639,7 +639,7 @@ print_screen_info(Display *dpy, int scrnum, Bool
allowDirect, Bool limits, Bool
printf(OpenGL renderer string: %s\n, glRenderer);
printf(OpenGL version string: %s\n, glVersion);
#ifdef GL_VERSION_2_0
- if (glVersion[0] = '2' glVersion[1] == '.') {
+ if (glVersion glVersion[0] = '2' glVersion[1] == '.') {
char *v = (char *) glGetString(GL_SHADING_LANGUAGE_VERSION);
printf(OpenGL shading language version string: %s\n, v);
}
Normally, this is a good idea. However, glVersion is already
dereferenced in the printf on the previous line. So, any actual
checking for NULL glVersion should at least come earlier in the
function. On the other hand, returning NULL from
glGetString(GL_VERSION) might be so rare that bothering to guard for
it would be more effort than it's worth.
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Save user {C, CXX}FLAGS and append them at end.
On Sun, Dec 23, 2012 at 3:41 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Am Samstag, 22. Dezember 2012, 16:34:48 schrieben Sie: On Sat, Dec 22, 2012 at 10:47 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Am Samstag, 22. Dezember 2012, 09:21:33 schrieb Matt Turner: On Sat, Dec 22, 2012 at 9:16 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: This way the user has the privilege of last decision and so the option to build an optimized debug build again. --- You can just do CFLAGS=-g -O2 ./configure can't you? Nope. CXXFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' CFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' ./autogen.sh --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --enable-xvmc --enable-vdpau --enable-texture-float --enable-debug --with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast --with-gallium-drivers=i915,nouveau,r300,r600,svga,swrast --enable-dri --enable-glx --enable-osmesa --enable-gles1 --enable-gles2 --enable-openvg --enable-shared-glapi --enable-shared-gallium --enable-gbm --enable-xa --ena ble-gallium-egl --enable-gallium-llvm --enable-gallium-gbm --enable-opencl --enable-r600-llvm-compiler --enable-gallium-g3dvl --enable-glx-tls Resulting Makefile: before: CFLAGS = -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O0 after: CFLAGS = -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O0 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g You see configure CFLAGS and initial CFLAGS are vice versa. The real fix here is not to have configure.ac touch CFLAGS at all like any reasonable autotools project. That was an unfortunate shortcut during the initial work. That would be a lot more effort, though. Initial work after ~ 5 years? http://cgit.freedesktop.org/mesa/mesa/commit/?id=122345876479cf5cf553e38162ab105658614ab7 Not sure what you mean by this. When I wrote configure.ac however many years ago, I didn't cleanly split off CFLAGS set by mesa from the user's CFLAGS as a shortcut. Looking back now, I should have just bit the bullet and made something like MESA_CFLAGS/MESA_LDFLAGS and made all the Makefiles use that. Btw: http://cgit.freedesktop.org/mesa/mesa/commit/?id=ff2efdf5997d20b41f7a82b77118366e6fbd23bc http://cgit.freedesktop.org/mesa/mesa/commit/?id=33ae29c93b8f70a86dcedc495dd658a5d5679db3 This patch covers the motivation for commit 33ae29c. However, the typical convention is that the user's CFLAGS come first (see any automake COMPILE or LTCOMPILE definition), mostly so that any user specified -I paths take precedence. That's unfortunate when -O options to gcc are last one wins, but that's how things have typically been. I would make this change very cautiously. -- Dan And here is the real reason for my request: /usr/lib64/mesa-demos/egl/opengl/xeglgears AMD Fusion (fps) Nvidia ION (fps) -O0 -O2 -O0 -O2 562,7 750,778 0,33641,851 921,464 0,44 701,756 662,877 -0,06 693,752 1000,1960,44 571,566 665,052 0,16692,196 936,147 0,35 542,715 664,658 0,22693,733 995,499 0,43 542,935 664,78 0,22692,702 992,634 0,43 542,574 665,398 0,23692,835 998,665 0,44 542,945 663,087 0,22691,353 998,319 0,44 541,732 664,253 0,23656,32 995,91 0,52 543,392 665,078 0,22691,084 994,037 0,44 542,901 663,406 0,22693,464 996,858 0,44 5635,2166729,3670,196839,29 9829,7290,44 (sum) - Performance + 19 % on AMD Fusion, + 44 % on Nvidia ION on debug build with -O2. :-) Usual users should build Mesa with default FLAGS. Advanced users should be able to build it with their own FLAGS without modifying source. Right, --enable-debug is forcing you to have -O0. That's the problem. Mesa should not be overriding user defined flags such as optimization unless it's necessary to get Mesa to build. There are two issues here: 1. Adding -O0 in --enable-debug is a convenience, but as you see it can conflicts with the user's flags.
Re: [Mesa-dev] [PATCH] configure.ac: Save user {C, CXX}FLAGS and append them at end.
On Sat, Dec 22, 2012 at 10:47 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: Am Samstag, 22. Dezember 2012, 09:21:33 schrieb Matt Turner: On Sat, Dec 22, 2012 at 9:16 AM, Johannes Obermayr johannesoberm...@gmx.de wrote: This way the user has the privilege of last decision and so the option to build an optimized debug build again. --- You can just do CFLAGS=-g -O2 ./configure can't you? Nope. CXXFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' CFLAGS='-fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g' ./autogen.sh --host=x86_64-suse-linux-gnu --build=x86_64-suse-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/lib --localstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --infodir=/usr/share/info --disable-dependency-tracking --enable-xvmc --enable-vdpau --enable-texture-float --enable-debug --with-dri-drivers=i915,i965,nouveau,r200,radeon,swrast --with-gallium-drivers=i915,nouveau,r300,r600,svga,swrast --enable-dri --enable-glx --enable-osmesa --enable-gles1 --enable-gles2 --enable-openvg --enable-shared-glapi --enable-shared-gallium --enable-gbm --enable-xa --e na ble-gallium-egl --enable-gallium-llvm --enable-gallium-gbm --enable-opencl --enable-r600-llvm-compiler --enable-gallium-g3dvl --enable-glx-tls Resulting Makefile: before: CFLAGS = -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O0 after: CFLAGS = -Wall -std=c99 -Werror=implicit-function-declaration -Werror=missing-prototypes -fno-strict-aliasing -fno-builtin-memcmp -g -O0 -fmessage-length=0 -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector -funwind-tables -fasynchronous-unwind-tables -g You see configure CFLAGS and initial CFLAGS are vice versa. The real fix here is not to have configure.ac touch CFLAGS at all like any reasonable autotools project. That was an unfortunate shortcut during the initial work. That would be a lot more effort, though. However, the typical convention is that the user's CFLAGS come first (see any automake COMPILE or LTCOMPILE definition), mostly so that any user specified -I paths take precedence. That's unfortunate when -O options to gcc are last one wins, but that's how things have typically been. I would make this change very cautiously. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] scons: Use X11 modules if X11 is available.
On Sat, Dec 15, 2012 at 5:34 PM, Vinson Lee v...@freedesktop.org wrote:
This patch fixes these build errors.
glxinit.c:18:25: error: GL/glxproto.h: No such file or directory
glxinit.c:19:26: error: GL/glxtokens.h: No such file or directory
Signed-off-by: Vinson Lee v...@freedesktop.org
---
src/gallium/state_trackers/egl/SConscript | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/gallium/state_trackers/egl/SConscript
b/src/gallium/state_trackers/egl/SConscript
index 2f7ac7e..43b9dcb 100644
--- a/src/gallium/state_trackers/egl/SConscript
+++ b/src/gallium/state_trackers/egl/SConscript
@@ -27,6 +27,7 @@ else:
if env['drm']:
env.PkgUseModules('DRM')
if env['x11']:
+env.PkgUseModules('X11')
env.Append(CPPDEFINES = ['HAVE_X11_BACKEND'])
env.Prepend(CPPPATH = [
'#/src/glx',
I'm not really familiar with the scons build, but would this make it
link with libX11 and friends? That seems like overkill when you just
need the glproto package installed to get the headers.
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Disable compiler optimizations when --enable-debug is set
On Dec 12, 2012 8:30 AM, Emil Velikov emil.l.veli...@gmail.com wrote: Signed-off-by: Emil Velikov emil.l.veli...@gmail.com Looks good. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: fix --without-glut
On Nov 13, 2012 11:09 PM, Ross Burton ross.bur...@intel.com wrote: The argument --without-glut is transformed to --with-glut=no, which the logic wasn't handling at all so --without-glut didn't work. Rewrite the logic to handle the case where the value passed to --with-glut is no. Signed-off-by: Ross Burton ross.bur...@intel.com --- configure.ac | 26 +++--- 1 file changed, 15 insertions(+), 11 deletions(-) diff --git a/configure.ac b/configure.ac index 8b2c359..fda3e60 100644 --- a/configure.ac +++ b/configure.ac @@ -67,21 +67,25 @@ DEMO_CFLAGS=$DEMO_CFLAGS $GL_CFLAGS DEMO_LIBS=$DEMO_LIBS $GL_LIBS dnl Check for GLUT -GLUT_CFLAGS= -GLUT_LIBS=-lglut -glut_enabled=yes +glut_enabled=no AC_ARG_WITH([glut], [AS_HELP_STRING([--with-glut=DIR], [glut install directory])], [GLUT_CFLAGS=-I$withval/include -GLUT_LIBS=-L$withval/lib -lglut]) -AC_CHECK_HEADER([GL/glut.h], - [], - [glut_enabled=no]) -AC_CHECK_LIB([glut], - [glutInit], - [], - [glut_enabled=no]) +GLUT_LIBS=-L$withval/lib -lglut], + [GLUT_CFLAGS= +GLUT_LIBS=-lglut] +) +AS_IF([test x$with_glut != xno], + [AC_CHECK_HEADER([GL/glut.h], + [], + [glut_enabled=no]) + AC_CHECK_LIB([glut], +[glutInit], +[], +[glut_enabled=no]) + glut_enabled=yes +]) This looks pretty good except that I think you need to temporarily add GLUT_CFLAGS to CFLAGS and GLUT_LIBS to LIBS so that the user specified prefix works for AC_CHECK*. On the other hand, at least mesa glut has a pkg-config file, so it might be easier to just require a glut with glut.pc. Not sure about the other gluts though. Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Don't fail if libX11 isn't installed
On Oct 8, 2012 10:49 PM, Matt Turner matts...@gmail.com wrote: On Mon, Oct 8, 2012 at 8:27 PM, Daniel Stone dan...@fooishbar.org wrote: configure.ac would previously refuse to complete if libX11 wasn't installed, even if we'd disabled GLX and weren't building an X11 EGL platform. Make the check simply set the no_x variable that's used (but never set) immediately below for what looks like this very case. Signed-off-by: Daniel Stone dan...@fooishbar.org --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 72c2b8c..8b727c0 100644 --- a/configure.ac +++ b/configure.ac @@ -816,7 +816,7 @@ if test x$enable_dri = xyes; then fi dnl Find out if X is available. -PKG_CHECK_MODULES([X11], [x11]) +PKG_CHECK_MODULES([X11], [x11], [no_x=no], [no_x=yes]) dnl Try to tell the user that the --x-* options are only used when dnl pkg-config is not available. This must be right after AC_PATH_XTRA. -- 1.7.10.4 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev Wow, it's been like that since 2008. Reviewed-by: Matt Turner matts...@gmail.com Originally configure basically supported only GLX either through DRI or Xlib, so Xlib was basically required. Not so much nowadays. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] build: Don't list glproto and dri2proto in pkg-config file
On Tue, Sep 11, 2012 at 5:10 PM, Matt Turner matts...@gmail.com wrote: No files provided by glproto or dri2proto are needed for building something with Mesa. Bugzilla: https://bugs.gentoo.org/show_bug.cgi?id=342393 --- Dan, does this make sense? Yeah, that's a good point. Although, I could have sworn that when at some point you did need glproto in order to #include glx.h. Good catch. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCHv2] automake: Honor GL_LIB for mangled/custom lib names
On Mon, Jul 23, 2012 at 08:29:55AM -0400, Brad King wrote: On 07/16/2012 09:10 AM, Brad King wrote: Use @GL_LIB@ in src/mesa/drivers/x11/Makefile.am to configure the library name. Also use this approach to simplify src/glx/Makefile.am and drop the HAVE_MANGLED_GL conditional. On 07/11/2012 04:05 PM, Dan Nicholson wrote: Looks good to me. I wonder if the HAVE_MANGLED_GL conditional can be dropped at this point? Anyway, Reviewed-by: Dan Nicholson dbn.li...@gmail.com Additional changes have been made on master which conflict with the previous patch, so here is another one rebased on 81de0431. I also dropped the HAVE_MANGLED_GL conditional as it no longer appears necessary. Please review this patch again when you get a chance. There is no rush, I just don't want it to be forgotten. Applied as 27382c0f. I had been hoping Eric would pick it up since I'm not really keeping up with master these days, but the change looked good enough to me. Thanks! -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor GL_LIB for mangled/custom lib names
On 7/11/12, Brad King brad.k...@kitware.com wrote: Commit 2d4b77c7 (automake: Convert src/mesa/drivers/x11/Makefile to automake, 2012-06-12) dropped the old Makefile, which used GL_LIB, and replaced it with a Makefile.am hard-coding the name GL. This broke handling of --enable-mangling and --with-gl-lib-name options which depend on GL_LIB to specify the GL library name. Use @GL_LIB@ in src/mesa/drivers/x11/Makefile.am to configure the library name. Also simplify src/glx/Makefile.am using this approach. While at it, fix the compatibility link we create in lib for the software-only driver to use version GL_MAJOR instead of hard-coding 1. --- On 07/11/2012 11:24 AM, Eric Anholt wrote: Brad King brad.k...@kitware.com writes: Upon closer inspection it *does* obviously drop use of GL_LIB. Now libGL is hard-coded in Makefile.am. Naive replacement like that below is not valid automake code AFAICT. I'm not familiar enough with automake to know how to make the library name configurable. Does anyone know? For the OSMesa changes, Laurent Carlier used @OSMESA_LIB@, so if you did this patch using @GL_LIB@, it would at least be consistent with that. Great, thanks! Here is a patch. Looks good to me. I wonder if the HAVE_MANGLED_GL conditional can be dropped at this point? Anyway, Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: convert libOSmesa building
On Jun 23, 2012 7:47 AM, Laurent Carlier lordhea...@gmail.com wrote: This also currently fix the installation of libOSmesa. --- configure.ac | 1 + src/mesa/drivers/osmesa/Makefile | 51 src/mesa/drivers/osmesa/Makefile.am | 50 +++ src/mesa/drivers/osmesa/Makefile.old | 51 4 files changed, 102 insertions(+), 51 deletions(-) delete mode 100644 src/mesa/drivers/osmesa/Makefile create mode 100644 src/mesa/drivers/osmesa/Makefile.am create mode 100644 src/mesa/drivers/osmesa/Makefile.old diff --git a/configure.ac b/configure.ac index 46265a2..0b4a6b7 100644 --- a/configure.ac +++ b/configure.ac @@ -2189,6 +2189,7 @@ AC_CONFIG_FILES([configs/current src/mesa/drivers/dri/radeon/Makefile src/mesa/drivers/dri/swrast/Makefile src/mesa/drivers/x11/Makefile + src/mesa/drivers/osmesa/Makefile src/mesa/gl.pc src/mesa/osmesa.pc]) diff --git a/src/mesa/drivers/osmesa/Makefile b/src/mesa/drivers/osmesa/Makefile deleted file mode 100644 index 39ab09a..000 --- a/src/mesa/drivers/osmesa/Makefile +++ /dev/null @@ -1,51 +0,0 @@ -# src/mesa/drivers/osmesa/Makefile for libOSMesa.so - -# Note that we may generate libOSMesa.so or libOSMesa16.so or libOSMesa32.so -# with this Makefile - - -TOP = ../../../.. - -include $(TOP)/configs/current - - - -SOURCES = osmesa.c - -OBJECTS = $(SOURCES:.c=.o) - -INCLUDE_DIRS = \ - -I$(TOP)/include \ - -I$(TOP)/src/mapi \ - -I$(TOP)/src/mesa \ - -I$(TOP)/src/mesa/main - -CORE_MESA = \ - $(TOP)/src/mesa/libmesa.a \ - $(TOP)/src/mapi/glapi/libglapi.a \ - $(TOP)/src/glsl/libglsl.a - -.c.o: - $(CC) -c $(INCLUDE_DIRS) $(CFLAGS) $ -o $@ - - -default: $(TOP)/$(LIB_DIR)/$(OSMESA_LIB_NAME) - - -# libOSMesa can be used in conjuction with libGL or with all other Mesa -# sources. We can also build libOSMesa16/libOSMesa32 by setting -# -DCHAN_BITS=16/32. -$(TOP)/$(LIB_DIR)/$(OSMESA_LIB_NAME): $(OBJECTS) $(CORE_MESA) - $(MKLIB) -o $(OSMESA_LIB) -linker '$(CXX)' -ldflags '$(LDFLAGS)' \ - -major $(MESA_MAJOR) -minor $(MESA_MINOR) -patch $(MESA_TINY) \ - -install $(TOP)/$(LIB_DIR) -cplusplus $(MKLIB_OPTIONS) \ - -id $(INSTALL_LIB_DIR)/lib$(OSMESA_LIB).$(MESA_MAJOR).dylib \ - $(OSMESA_LIB_DEPS) $(OBJECTS) $(CORE_MESA) - - - -clean: - -rm -f *.o *~ - - -# XXX todo install rule? diff --git a/src/mesa/drivers/osmesa/Makefile.am b/src/mesa/drivers/osmesa/Makefile.am new file mode 100644 index 000..6542722 --- /dev/null +++ b/src/mesa/drivers/osmesa/Makefile.am @@ -0,0 +1,50 @@ + + +# Copyright © 2012 Matt Turner matts...@gmail.com +# +# 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. + +# Hack to make some of the non-automake variables work. +TOP=$(top_builddir) + +AM_CFLAGS = \ + -I$(top_srcdir)/include \ + -I$(top_srcdir)/src/mapi \ + -I$(top_srcdir)/src/mesa/ \ + $(DEFINES) \ + $(API_DEFINES) + +if HAVE_OSMESA_DRIVER +lib_LTLIBRARIES = lib@OSMESA_LIB@.la +endif + +lib@OSMESA_LIB@_la_SOURCES = osmesa.c + +lib@OSMESA_LIB@_la_LDFLAGS = -module -avoid-version -shared The rest of it looks pretty reasonable but here you're dropping the osmesa version number. Previously it was using the mesa version. The only other there thing about osmesa is that there ate many ways to build and link it. This might all be handled in configure but it would be worth investigating a bit. Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Mesa: Fix a race in the build
On Tue, Jun 12, 2012 at 3:52 PM, Mike Frysinger vap...@chromium.org wrote: On Tue, Jun 12, 2012 at 6:47 PM, Dan Nicholson dbn.li...@gmail.com wrote: On 6/12/12, Stéphane Marchesin marc...@chromium.org wrote: From: Mike Frysinger vap...@chromium.org The intent of the message above it is right (we need to build those dependencies in that order) but the implementation is wrong, as it can be executed in any order. To enforce the order, invoke make multiple times. --- src/mesa/Makefile | 8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/src/mesa/Makefile b/src/mesa/Makefile index b0b461f..c436890 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -33,8 +33,12 @@ MESA_CXXFLAGS := $(LLVM_CFLAGS) $(CXXFLAGS) $(CC) -c -o $@ $ $(MESA_CPPFLAGS) $(MESA_CFLAGS) # Default: build dependencies, then asm_subdirs, GLSL built-in lib, -# then convenience libs (.a) and finally the device drivers: -default: $(DEPENDS) asm_subdirs $(MESA_LIBS) driver_subdirs +# then convenience libs (.a) and finally the device drivers. +# To ensure ordering, we have to invoke make each time: +default: $(DEPENDS) + $(MAKE) asm_subdirs + $(MAKE) $(MESA_LIBS) + $(MAKE) driver_subdirs .PHONY: main/git_sha1.h.tmp main/git_sha1.h.tmp: The alternative that's more correct is to encode the dependencies in the right locations. I.e., make $(DEPENDS) a prereq for asm_subdirs, asm_subdirs as prereq for $(MESA_LIBS), etc. That enforces the order in the correct place and allows you to do something like make driver_dirs and have it work correctly. Some of that is already there, and it would be useful to know which part is racing. I suppose if no one is going to do that work, though... the trouble is that w/out GNU make, you can't declare a dependency as order-only. so by having $(MESA_LIBS) depend on asm_subdirs (which is a PHONY target), things end up getting regenerated all the time. Right, PHONY asm_subdirs does break that. Looking back into this now, I'm surprised it's broken. This did work for a long time. The reason is because MESA_LIBS will not be built until asm_subdirs is completed. This is because MESA_OBJECTS and MESA_GALLIUM_OBJECTS contain MESA_ASM_FILES, which are what's produced by descending through asm_subdirs. So, make will have to wait for asm_subdirs to complete before it can try to link libmesa.a or libgallium.a. I suspect what's broken this now is prefixing all the sources in sources.mak with $(SRCDIR). At least, I'd really like to see an actual error. FWIW, mesa does require GNU make in many other parts of the build. And if it get's changed to anything it will be automake where you could handle these issues in a reasonable way with automake conditionals or libtool convenience libraries. If things can't be made to work as I've suggested above, though, your serialization patch makes sense. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Mesa: Fix a race in the build
On 6/13/12, Mike Frysinger vap...@chromium.org wrote:
On Wed, Jun 13, 2012 at 8:13 AM, Dan Nicholson dbn.li...@gmail.com wrote:
On Tue, Jun 12, 2012 at 3:52 PM, Mike Frysinger vap...@chromium.org
wrote:
On Tue, Jun 12, 2012 at 6:47 PM, Dan Nicholson dbn.li...@gmail.com
wrote:
On 6/12/12, Stéphane Marchesin marc...@chromium.org wrote:
From: Mike Frysinger vap...@chromium.org
The intent of the message above it is right (we need to build those
dependencies in that order) but the implementation is wrong, as it
can be executed in any order. To enforce the order, invoke make
multiple times.
---
src/mesa/Makefile |8 ++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/mesa/Makefile b/src/mesa/Makefile
index b0b461f..c436890 100644
--- a/src/mesa/Makefile
+++ b/src/mesa/Makefile
@@ -33,8 +33,12 @@ MESA_CXXFLAGS := $(LLVM_CFLAGS) $(CXXFLAGS)
$(CC) -c -o $@ $ $(MESA_CPPFLAGS) $(MESA_CFLAGS)
# Default: build dependencies, then asm_subdirs, GLSL built-in lib,
-# then convenience libs (.a) and finally the device drivers:
-default: $(DEPENDS) asm_subdirs $(MESA_LIBS) driver_subdirs
+# then convenience libs (.a) and finally the device drivers.
+# To ensure ordering, we have to invoke make each time:
+default: $(DEPENDS)
+ $(MAKE) asm_subdirs
+ $(MAKE) $(MESA_LIBS)
+ $(MAKE) driver_subdirs
.PHONY: main/git_sha1.h.tmp
main/git_sha1.h.tmp:
The alternative that's more correct is to encode the dependencies in
the right locations. I.e., make $(DEPENDS) a prereq for asm_subdirs,
asm_subdirs as prereq for $(MESA_LIBS), etc. That enforces the order
in the correct place and allows you to do something like make
driver_dirs and have it work correctly. Some of that is already
there, and it would be useful to know which part is racing. I suppose
if no one is going to do that work, though...
the trouble is that w/out GNU make, you can't declare a dependency as
order-only. so by having $(MESA_LIBS) depend on asm_subdirs (which is
a
PHONY target), things end up getting regenerated all the time.
Right, PHONY asm_subdirs does break that. Looking back into this now,
I'm surprised it's broken. This did work for a long time. The reason
is because MESA_LIBS will not be built until asm_subdirs is completed.
This is because MESA_OBJECTS and MESA_GALLIUM_OBJECTS contain
MESA_ASM_FILES, which are what's produced by descending through
asm_subdirs. So, make will have to wait for asm_subdirs to complete
before it can try to link libmesa.a or libgallium.a. I suspect what's
broken this now is prefixing all the sources in sources.mak with
$(SRCDIR). At least, I'd really like to see an actual error.
iirc, the debug+fix session happened on irc, so i didn't post any of the
errors, and the log files we were reviewing no longer exist on the bots.
the error is related to not building in subdirs anymore. look at
src/mesa/{x86,x86-64}/Makefile -- you'll see that there's a matypes.h
header generated, and the objects declare dependencies on that. but that
isn't bubbled up, so if you build asm_subdirs and $(MESA_LIBS) in parallel,
the objects that need matypes.h are built before matypes.h is generated.
Hmm, I recall that had worked at one point, but looking again I don't
see how. I think your patch is correct and essentially does the same
thing as automake in serializing the directory recursion but without
all the generic syntax. Essentially this is like SUBDIRS = x86 x86-64
. drivers on x86_64 with the extra nit that DEPENDS happens at the
beginning and not at the same time as the . directory.
Reviewed-by: Dan Nicholson dbn.li...@gmail.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/19] automake: Don't warn on gmake portability issues.
On 6/13/12, Eric Anholt e...@anholt.net wrote: Even pre-automake, we rely on gmake features for pattern substitutions, and replacing those with reams more make code is not interesting. This will let us turn the old Makefiles using pattern substitutions into automake without spewing warnings. --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 29ee87b..19c5111 100644 --- a/configure.ac +++ b/configure.ac @@ -10,7 +10,7 @@ AC_INIT([Mesa], [8.1.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=Mesa]) AC_CONFIG_AUX_DIR([bin]) AC_CANONICAL_HOST -AM_INIT_AUTOMAKE([foreign -Wall]) +AM_INIT_AUTOMAKE([foreign]) dnl http://people.gnome.org/~walters/docs/build-api.txt dnl We don't support srcdir != builddir. Reviewed-by: Dan Nicholson dbn.li...@gmail.com Like I was saying yesterday, if there are other useful warnings in -Wall, you can specifically turn off the gmake warning by adding -Wno-portability. I think this is fine, though. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] automake continued
On 6/13/12, Eric Anholt e...@anholt.net wrote: Here's a bunch more automake. We're at the point that an enterprising person could potentially convert libmesa.a if they figure out how to work that into the gallium build. I also haven't converted osmesa, because I didn't think I knew of any tests for it (but wait, there's mesa-demos). Nice job, Eric. I'll try to look through the patches, but no promises. I've added Gaetan on since he's essentially the autotools guru on xorg now. Gaetan, I have no idea how (or if) you'll respond to these patches, but you can try to look at them in the archives I suppose. http://lists.freedesktop.org/archives/mesa-dev/2012-June/022883.html http://thread.gmane.org/gmane.comp.video.mesa3d.devel/41416 -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): automake: Add a prefix variable for libglsl sources.
On 6/11/12, Eric Anholt e...@anholt.net wrote: On Mon, 11 Jun 2012 10:02:34 -0700 (PDT), Jose Fonseca jfons...@vmware.com wrote: This breaks the SCons build, which parses src/glsl/Makefile.sources, and can't understand $(GLSL_SRCDIR)/ as it only supports a simple subset of Make syntax. Is there some other way to achieve this effect, without changing src/glsl/Makefile.sources? Thanks for pushing the fix -- looks fine. It turns out that while working on my next series of automaking, I've found that there's a knob to tell automake to stfu about use of gmake features, so this dance may not actually be required. FYI, it's -Wall in AM_INIT_AUTOMAKE from e4c97f1e6 that's doing this. foreign shuts off the portability warnings. http://www.gnu.org/software/automake/manual/automake.html#automake-Invocation http://www.gnu.org/software/automake/manual/automake.html#Strictness Since I'm pretty sure there are quite a few parts of the build that depend on GNU Make, I'd suggest either dropping -Wall or adding -Wno-portability. I don't see how -Wall is helping here, though. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On 6/4/12, Brad King brad.k...@kitware.com wrote:
On 06/01/2012 05:49 PM, Dan Nicholson wrote:
+AC_ARG_VAR([GL_LIB],[name of GL library @:@default=GL@:@])
+AC_ARG_VAR([GLU_LIB],[name of GLU library @:@default=GLU@:@])
+AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library
@:@default=OSMesa@:@])
+GL_LIB=${GL_LIB-GL}
+GLU_LIB=${GLU_LIB-GLU}
+OSMESA_LIB=${OSMESA_LIB-OSMesa}
I don't think this part is necessary. AC_ARG_VAR does this already. The
rest makes sense though.
Thanks for taking a look. I think the init lines are needed in
order to set the default values. With the patch below on top of
this one I get output
GL_LIB=
GLU_LIB=
OSMESA_LIB=
and the build fails. I see no mention in AC_ARG_VAR documentation
about default value selection:
http://www.gnu.org/software/autoconf/manual/autoconf-2.67/html_node/Setting-Output-Variables.html#index-AC_005fARG_005fVAR-1134
Duh, you're right. I think this original patch is good to go. The
variables should be substituted in configs/autoconf and a quick grep
shows that there are no remaining hardcoded -lGL around (I think).
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] automake: Honor (GL|GLU|OSMESA)_LIB from environment
On Jun 1, 2012 12:13 PM, Brad King brad.k...@kitware.com wrote:
Teach 'configure' to read the default GL_LIB, GLU_LIB, and OSMESA_LIB
values from the environment. This allows one to mangle the library
names (without also mangling the symbol names) to make them distinct
from other GL libraries on the system.
---
On 06/01/2012 10:06 AM, Brian Paul wrote:
You should transition to using autoconf
One feature I used in the pure-make build system was to create a custom
configs/current to set GL_LIB, GLU_LIB, and OSMESA_LIB to have a Mesa
prefix. This helps ensure that VTK both builds and runs against my
nightly Mesa build regardless of what other GL libraries appear in
the dynamic loader's search path. With this patch I can run
$ GL_LIB=MesaGL GLU_LIB=MesaGLU OSMESA_LIB=MesaOSMesa ./autogen.sh ...
to build with custom library names. Please review.
Thanks,
-Brad
configure.ac | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index 9fb8149..7f6ba96 100644
--- a/configure.ac
+++ b/configure.ac
@@ -355,6 +355,12 @@ else
LIB_EXTENSION='so' ;;
esac
fi
+AC_ARG_VAR([GL_LIB],[name of GL library @:@default=GL@:@])
+AC_ARG_VAR([GLU_LIB],[name of GLU library @:@default=GLU@:@])
+AC_ARG_VAR([OSMESA_LIB],[name of OSMesa library @:@default=OSMesa@:@])
+GL_LIB=${GL_LIB-GL}
+GLU_LIB=${GLU_LIB-GLU}
+OSMESA_LIB=${OSMESA_LIB-OSMesa}
I don't think this part is necessary. AC_ARG_VAR does this already. The
rest makes sense though.
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] No more make clean!
On May 25, 2012 7:23 AM, Brian Paul bri...@vmware.com wrote: On 05/24/2012 05:45 PM, Eric Anholt wrote: It still has the flaw that changes to source lists and Makefile.ams don't rebuild Makefile as often as they should. This is because our top-level Makefile isn't in automake, and has just a stub am-refresh target. I have a series to convert that, but it means getting rid of the static configs. I'd love to see them die (they're just a trap these days), but I'll wait on that for another patchbomb. I'm fine with removing the old/static configs. I've been using autoconf for a few months now and I'm mostly happy with it. One thing I wish was different is the --enable-debug option. It adds -g to the command line, but the -O2 flag is still there and that sometimes causes trouble in gdb. To fix that I have to do CFLAGS=-g ./autogen Could we fix the --enable-debug option to remove -O2? In my own automake branch that I stalled on I had the idea of turning the static configs into configure wrapper scripts that just help you do known things like set debug flags. Any interest? Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] autoconf: add AM_PROG_CC_C_O
On 4/13/12, Olivier Galibert galib...@pobox.com wrote: On Fri, Apr 13, 2012 at 11:06:18AM -0700, Ian Romanick wrote: On 04/13/2012 08:47 AM, nobled wrote: Prevents this error with Automake 1.9: src/gallium/drivers/Makefile.am: C objects in subdir but `AM_PROG_CC_C_O' not in `configure.ac' autoreconf: automake failed with exit status: 1 What the heck is the difference between AM_PROG_CC_C_0 and AC_PROG_CC? Are both really necessary? Seems like... madness. Isn't AM_PROG_CC_C_O the test whether the compiler can do both -c and -o in the same command line (w.r.t -c only + mv which was needed for some stupid compilers)? Yeah. If you have objects in subdirs, you either have to use -o to send the objects there or automake has to use the compile script to do it for you. It would be nice if it added this for you when you used subdir-objects, though... -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] r300g: Use automake to generate Makefile
On Feb 19, 2012 7:39 PM, Tom Stellard tstel...@gmail.com wrote: On Sun, Feb 19, 2012 at 10:13:48PM -0500, Matt Turner wrote: Hi Tom, Very happy to see this. It looks good, and I'm glad that you replaced two Makefiles with only a single Makefile.am. A couple of comments below. On Sun, Feb 19, 2012 at 10:05 PM, Tom Stellard tstel...@gmail.com wrote: --- configure.ac |1 + src/gallium/drivers/r300/.gitignore|5 ++ src/gallium/drivers/r300/Makefile | 25 - src/gallium/drivers/r300/Makefile.am | 38 ++ src/gallium/drivers/r300/compiler/tests/.gitignore |1 - src/gallium/drivers/r300/compiler/tests/Makefile | 53 6 files changed, 44 insertions(+), 79 deletions(-) create mode 100644 src/gallium/drivers/r300/.gitignore delete mode 100644 src/gallium/drivers/r300/Makefile create mode 100644 src/gallium/drivers/r300/Makefile.am delete mode 100644 src/gallium/drivers/r300/compiler/tests/.gitignore delete mode 100644 src/gallium/drivers/r300/compiler/tests/Makefile diff --git a/configure.ac b/configure.ac index 846b623..85da4d3 100644 --- a/configure.ac +++ b/configure.ac @@ -1871,6 +1871,7 @@ if test x$with_gallium_drivers != x; then gallium_require_llvm Gallium R300 GALLIUM_DRIVERS_DIRS=$GALLIUM_DRIVERS_DIRS r300 gallium_check_st radeon/drm dri-r300 xorg-r300 xvmc-r300 vdpau-r300 va-r300 +AC_CONFIG_FILES([src/gallium/drivers/r300/Makefile]) Just add this to the existing AC_CONFIG_FILES around line 1934. I put it here so the Makefile would only be generated if the r300 driver was actually being built. Is there any advantage to generating all the Makefiles unconditionally? I think autoconf will fill in anything it finds in AC_CONFIG_FILES regardless. There's no real harm. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Enable GLX_USE_TLS if possible.
On Wed, Feb 8, 2012 at 5:11 PM, Zhigang Gong
zhigang.g...@linux.intel.com wrote:
On Wed, Feb 08, 2012 at 02:46:42PM -0800, Eric Anholt wrote:
On Wed, 8 Feb 2012 16:19:38 +0800, zhigang.g...@linux.intel.com wrote:
From: Zhigang Gong zhigang.g...@linux.intel.com
If the system support tls, we prefer to enable it by default
just as xserver does. Actually, the checking code is copied
from xserver/configure.ac.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
configure.ac | 10 --
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index b2b1ab8..7c2756b 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1103,8 +1103,14 @@ dnl
AC_ARG_ENABLE([glx-tls],
[AS_HELP_STRING([--enable-glx-tls],
[enable TLS support in GLX @:@default=disabled@:@])],
-[GLX_USE_TLS=$enableval],
-[GLX_USE_TLS=no])
+[GLX_USE_TLS=$enableval
+ if test x$GLX_USE_TLS = xyes test ${ac_cv_tls} = none ;
then
+AC_MSG_ERROR([GLX with TLS support requested, but the compiler
does not support it.])
+ fi],
+[GLX_USE_TLS=no
+ if test ${ac_cv_tls} != none ; then
+GLX_USE_TLS=yes
+ fi])
AC_SUBST(GLX_TLS, ${GLX_USE_TLS})
I don't think you have anything setting ac_cv_tls.
You are right, I forgot to add the checking code which is also from xserver.
Sorry for that, here is the v2 patch:
From: Zhigang Gong zhigang.g...@linux.intel.com
Date: Wed, 8 Feb 2012 16:12:42 +0800
Subject: [PATCH v2] configure.ac: Enable GLX_USE_TLS if possible.
If the system support tls, we prefer to enable it by default
just as xserver does. Actually, the checking code is copied
from xserver/configure.ac.
Signed-off-by: Zhigang Gong zhigang.g...@linux.intel.com
---
configure.ac | 39 +--
1 files changed, 37 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index b2b1ab8..3dfafba 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1099,12 +1099,47 @@ esac
dnl
dnl TLS detection
dnl
+AC_MSG_CHECKING(for thread local storage (TLS) support)
+AC_CACHE_VAL(ac_cv_tls, [
+ac_cv_tls=none
+keywords=__thread __declspec(thread)
+for kw in $keywords ; do
+AC_TRY_COMPILE([int $kw test;], [], ac_cv_tls=$kw)
+done
+])
+AC_MSG_RESULT($ac_cv_tls)
+
+if test $ac_cv_tls != none; then
+AC_MSG_CHECKING(for tls_model attribute support)
+AC_CACHE_VAL(ac_cv_tls_model, [
+save_CFLAGS=$CFLAGS
+CFLAGS=$CFLAGS $STRICT_CFLAGS
+AC_TRY_COMPILE([int $ac_cv_tls
__attribute__((tls_model(initial-exec))) test;], [],
+ ac_cv_tls_model=yes, ac_cv_tls_model=no)
+CFLAGS=$save_CFLAGS
+])
+AC_MSG_RESULT($ac_cv_tls_model)
+
+if test x$ac_cv_tls_model = xyes ; then
+mesa_tls=$ac_cv_tls' __attribute__((tls_model(initial-exec)))'
+else
+mesa_tls=$ac_cv_tls
+fi
+
+AC_DEFINE_UNQUOTED([TLS], $mesa_tls, [The compiler supported TLS storage
class, prefering initial-exec if tls_model is supported])
+fi
Can you put this code in acinclude.m4 and call it MESA_TLS or
something? There's a couple minor issues with copying this straight
from the xserver.
1. STRICT_FLAGS isn't set anywhere. This would come from
XORG_STRICT_OPTION, but I don't think we should pull that in here. I
think you can just drop the save_CFLAGS dance and just call
AC_TRY_COMPILE straight off. The main thing we're losing is possibly
having -Werror set during the run, but then you have to figure out if
that's OK to set or not. Seems easier to just see if the compiler will
bomb with whatever flags are set at the time.
2. Also, the AC_DEFINE_UNQUOTED is not needed since mesa doesn't use
config.h. If you want -DTLS in the code, I think you should add that
to DEFINES. Or make a new variable TLS_FLAGS and add it to CFLAGS in
configs/autoconf.in. Look at how PIC_FLAGS is used if you want this.
Probably this line should just be removed, though, since configure.ac
is already setting -DGLX_USE_TLS and that's used in the code.
AC_ARG_ENABLE([glx-tls],
[AS_HELP_STRING([--enable-glx-tls],
[enable TLS support in GLX @:@default=disabled@:@])],
You should change this to default:auto since the default case is
turning on TLS when the compiler says we have it.
-[GLX_USE_TLS=$enableval],
-[GLX_USE_TLS=no])
+[GLX_USE_TLS=$enableval
+ if test x$GLX_USE_TLS = xyes test ${ac_cv_tls} = none ; then
+AC_MSG_ERROR([GLX with TLS support requested, but the compiler does
not support it.])
+ fi],
+[GLX_USE_TLS=no
+ if test ${ac_cv_tls} != none ; then
+GLX_USE_TLS=yes
+ fi])
AC_SUBST(GLX_TLS, ${GLX_USE_TLS})
AS_IF([test x$GLX_USE_TLS = xyes],
The rest looks good. With those couple fixes,
Reviewed-by: Dan Nicholson dbn.li...@gmail.com
___
mesa-dev
Re: [Mesa-dev] [PATCH 4/4] configure.ac: remove shared/static options
On Fri, Jan 20, 2012 at 12:57 PM, Matt Turner matts...@gmail.com wrote: On Sat, Jan 14, 2012 at 11:16 AM, Matt Turner matts...@gmail.com wrote: now that libtool provides them. Signed-off-by: Matt Turner matts...@gmail.com --- Ping. This is sensible, right? Sorry, I missed this. I _think_ so. I'm kind of wary of relying on a bolted on libtool rather than a fully integrated libtool, but I think for the purpose of these variables it should be fine. Did you actually check that LT_INIT sets enable_shared and enable_static like we're using here? I'm pretty sure it does, but I'd appreciate if you could take a look. If that's the case, Reviewed-by: Dan Nicholson dbn.li...@gmail.com -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Add an autoconf option for mangling Mesa.
Sorry, life's extremely busy for me. Looks good at a glance. I didn't check
if GL is hardcoded in spots where $(GL_LIB) should be used or anything like
that, though.
Reviewed-by: Dan Nicholson dbn.li...@gmail.com
On Oct 12, 2011 1:30 PM, tom fogal tfo...@sci.utah.edu wrote:
*ping* any review?
Dan, I think you're probably the best to review this, if you have a
minute.
-tom
tfo...@sci.utah.edu writes:
From: Tom Fogal tfo...@alumni.unh.edu
In addition to setting up the flags correctly, this renames the
generated libraries to ensure they get 'Mangled' in the name.
This is very useful for distros and the like, where mangled Mesa
and non-mangled GL libraries typically need to be installed
side-by-side.
---
configs/autoconf.in |4 ++--
configure.ac| 27 ---
2 files changed, 26 insertions(+), 5 deletions(-)
diff --git a/configs/autoconf.in b/configs/autoconf.in
index 9bbafc9..96fe5da 100644
--- a/configs/autoconf.in
+++ b/configs/autoconf.in
@@ -64,8 +64,8 @@ FLEX = @FLEX@
BISON = @BISON@
# Library names (base name)
-GL_LIB = GL
-GLU_LIB = GLU
+GL_LIB = @GL_LIB@
+GLU_LIB = @GLU_LIB@
GLW_LIB = GLw
OSMESA_LIB = @OSMESA_LIB@
GLESv1_CM_LIB = GLESv1_CM
diff --git a/configure.ac b/configure.ac
index 49e81ad..df909dd 100644
--- a/configure.ac
+++ b/configure.ac
@@ -342,6 +342,28 @@ else
fi
dnl
+dnl Mangled Mesa support
+dnl
+AC_ARG_ENABLE([mangling],
+ [AS_HELP_STRING([--enable-mangling],
+[enable mangled symbols and library name @:@default=disabled@
:@])],
+ [enable_mangling=${enableval}],
+ [enable_mangling=no]
+)
+GL_LIB=GL
+GLU_LIB=GLU
+OSMESA_LIB=OSMesa
+if test x${enable_mangling} = xyes ; then
+ DEFINES=${DEFINES} -DUSE_MGL_NAMESPACE
+ GL_LIB=MangledGL
+ GLU_LIB=MangledGLU
+ OSMESA_LIB=MangledOSMesa
+fi
+AC_SUBST([GL_LIB])
+AC_SUBST([GLU_LIB])
+AC_SUBST([OSMESA_LIB])
+
+dnl
dnl potentially-infringing-but-nobody-knows-for-sure stuff
dnl
AC_ARG_ENABLE([texture-float],
@@ -1280,17 +1302,16 @@ if test x$osmesa_bits != x8; then
fi
case x$osmesa_bits in
x8)
-OSMESA_LIB=OSMesa
+OSMESA_LIB=${OSMESA_LIB}
;;
x16|x32)
-OSMESA_LIB=OSMesa$osmesa_bits
+OSMESA_LIB=${OSMESA_LIB}$osmesa_bits
DEFINES=$DEFINES -DCHAN_BITS=$osmesa_bits
-DDEFAULT_SOFTWARE_DEPTH_BITS
=31
;;
*)
AC_MSG_ERROR([OSMesa bits '$osmesa_bits' is not a valid option])
;;
esac
-AC_SUBST([OSMESA_LIB])
if test x$enable_osmesa = xyes; then
# only link libraries with osmesa if shared
--
1.7.3.4
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/
Hi Matt, On Sat, Sep 24, 2011 at 6:06 PM, Matt Turner matts...@gmail.com wrote: Signed-off-by: Matt Turner matts...@gmail.com --- The last discussion about using automake ([RFC] Convert mesa to automake/libtool) ended without anything happening, probably because the branch wasn't ready. This patch is an attempt to get the ball rolling again. Without ripping out the entire existing build system in one swat, it attempts to gradually replace it directory by directory with automake. The patch has a few problems currently, and a few things that can possibly be done better: - Mainly, that building libmesa.a currently fails. - Not sure how to handle shared/static dricore options. - libtool defines VERSION (-DVERSION=...), which screws up the VERSION token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it. - libralloc.la can probably be combined into libglslcore.la, and not have to be added to every _LDADD line. - The rules for flex and bison can probably be eliminated by using YFLAGS and LFLAGS. I tried, but ylwrap gave me some error. I also killed off what looks to be a stray autogen.sh in src/glsl/. Please give it a test. Sorry for not replying sooner. I've been too busy to attend to my rapidly growing inbox. I agree wholeheartedly with the change to automake, although I think eventually you need Brian's buy in. Despite its flaws, the custom Makefile system has worked for a lot of years. That said, I think some of the issues can be conquered with documentation and education. I also think the best feature of the current system, the static configuration templates in configs/, can be emulated under autotools. Anyway, I haven't looked closely at the patch, but I would echo Gaetan's sentiment to start at the root Makefile.am and work down. I did some work on this before I got busy. The commits are not really clean, but you can get them in the automake branch in ~dbn/mesa.git on annarchy. I think there's definitely a way to move along piecemeal with a few suggestions: - Don't feel the need to completely transform a whole Makefile in one shot. This patch works on a fairly standalone piece, but once you get into the intertwined parts you either end up with a megacommit or find a way to work with smaller pieces. You can use the -local automake targets to point to the existing rules instead of changing to the automatic rules immediately. - Some of the current make variables are constructed in configs/default and configs/autoconf right now. You'll either need to expand those in each Makefile you convert or just continue to source $(top_builddir)/configs/current for a while. - The default targets in the old Makefiles need to be changed to all so the the root automaked Makefile calls the right thing when descending. I'm sure there's a ton of other gotchas. Anyway, I hope to get back to this sometime. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/
On Sat, Sep 24, 2011 at 6:06 PM, Matt Turner matts...@gmail.com wrote:
Signed-off-by: Matt Turner matts...@gmail.com
---
The last discussion about using automake ([RFC] Convert mesa to
automake/libtool)
ended without anything happening, probably because the branch wasn't ready.
This patch is an attempt to get the ball rolling again. Without ripping out
the entire existing build system in one swat, it attempts to gradually replace
it directory by directory with automake.
The patch has a few problems currently, and a few things that can possibly be
done better:
- Mainly, that building libmesa.a currently fails.
- Not sure how to handle shared/static dricore options.
- libtool defines VERSION (-DVERSION=...), which screws up the VERSION
token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it.
- libralloc.la can probably be combined into libglslcore.la, and not
have to be added to every _LDADD line.
- The rules for flex and bison can probably be eliminated by using
YFLAGS and LFLAGS. I tried, but ylwrap gave me some error.
I also killed off what looks to be a stray autogen.sh in src/glsl/.
Please give it a test.
Thanks,
Matt
configure.ac | 10 ++
src/glsl/Makefile | 235
---
src/glsl/Makefile.am | 146 +
src/glsl/autogen.sh | 12 ---
src/glsl/glsl_lexer.ll | 4 +-
src/glsl/glsl_parser.yy | 6 +-
6 files changed, 161 insertions(+), 252 deletions(-)
delete mode 100644 src/glsl/Makefile
create mode 100644 src/glsl/Makefile.am
delete mode 100755 src/glsl/autogen.sh
diff --git a/configure.ac b/configure.ac
index b2606bf..fd1082d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -17,6 +17,13 @@ AC_INIT([Mesa],[mesa_version],
AC_CONFIG_AUX_DIR([bin])
AC_CANONICAL_HOST
+# Initialize Automake
+AM_INIT_AUTOMAKE([foreign dist-bzip2])
+AM_MAINTAINER_MODE
+
+# Initialize libtool
+AC_PROG_LIBTOOL
+
dnl Save user CFLAGS and CXXFLAGS so one can override the default ones
USER_CFLAGS=$CFLAGS
USER_CXXFLAGS=$CXXFLAGS
@@ -2010,3 +2017,6 @@ echo PYTHON2: $PYTHON2
echo
echo Run '${MAKE-make}' to build Mesa
echo
+
+AC_CONFIG_FILES([src/glsl/Makefile])
+AC_OUTPUT
Just a quick note that there are already AC_CONFIG_FILES and AC_OUTPUT
calls in configure.ac, so you should be able to use those.
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC PATCH] automake: add support to src/glsl/
On Sun, Sep 25, 2011 at 12:06 PM, Gaetan Nadon mems...@videotron.ca wrote: On Sat, 2011-09-24 at 21:06 -0400, Matt Turner wrote: The patch has a few problems currently, and a few things that can possibly be done better: - Mainly, that building libmesa.a currently fails. - Not sure how to handle shared/static dricore options. - libtool defines VERSION (-DVERSION=...), which screws up the VERSION token in glsl_lexer.ll and glsl_parser.yy. I trivially renamed it. - libralloc.la can probably be combined into libglslcore.la, and not have to be added to every _LDADD line. - The rules for flex and bison can probably be eliminated by using YFLAGS and LFLAGS. I tried, but ylwrap gave me some error. I had a quick look, configure.ac is huge and has a big impact on Makefiles. I think it should be reviewed and cleaned-up to understand how it affects makefiles. Just a few examples of statements to investigate. Not that they are bad, but they may be needed because there was no automake and they could possibly conflict. AC_CHECK_PROGS([MAKE], [gmake make]) AC_PATH_PROG([MKDEP], [makedepend]) Can 'makedepend' impact the dependencies automake generates? AC_PATH_PROG([FLEX], [flex]) AC_PATH_PROG([BISON], [bison]) Some platforms have different names. The rules in the automake make file may not work if configure.ac does not use AC_PROG_YACC and AC_PROG_LEX This is the configuration in xorg: AC_PROG_YACC AC_PATH_PROG([YACC_INST], $YACC) if test ! -f $srcdir/gram.c; then if test -z $YACC_INST; then AC_MSG_ERROR([yacc not found - unable to compile gram.y]) fi fi AC_PROG_LEX test x$INSTALL = x$ac_install_sh INSTALL='$(MINSTALL)' On some platforms, this may result in a different install program being used whether the makefile is from mesa or automake. There is a 'configuration' file. How will the automake makefiles take that into account. It looks like there are 'conflicts' between mesa makefiles and automake which is expected due to the size of the project. Some preparation work should be done upfront to make both system coexist and then have automake gradually replace mesa makefiles. This would be useful work anyway. Just a quick note that there are a lot of custom things in the current configure.ac to make things work better with the current system. Until that system is completely gone, a lot of the hacks in here need to remain. So, I'd suggest leaving configure.ac mostly as is unless there's a specific thing that's breaking automake. You can certainly clean up a lot of things in there if automake is used through the whole tree, but that's a ways off. -- 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 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] Removing GLw from the main Mesa repository
On Fri, Aug 5, 2011 at 6:45 AM, Brian Paul brian.e.p...@gmail.com wrote: On Thu, Aug 4, 2011 at 4:26 PM, Kenneth Graunke kenn...@whitecape.org wrote: Hey, I'd like to remove libGLw from the main Mesa repository. It never changes, and almost noone uses it...because GL and Motif is awesome, right? Since Debian still packages it, I pulled it into its own git repository, preserving history, and then autotooled it. You can get it here: git://people.freedesktop.org/~kwg/glw Sounds good to me. Please scan through the Mesa docs for any mention of libGLw and update/remove as needed. There should at least be a pointer to the new home of libGLw too. Can we make this mesa/glw eventually to live alongside glut? -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Removing GLw from the main Mesa repository
On Fri, Aug 5, 2011 at 7:25 AM, Benjamin Franzke benjaminfran...@googlemail.com wrote: There is nothing compiled since GLW_SOURCES is not substituted by configure: Makefile.am:29 libGLw_la_SOURCES = $(GLW_SOURCES) This would need AC_SUBST([GLW_SOURCES]) in configure.ac, but thats not allowed for _SOURCES variables, see automake output: configure.ac:96: `GLW_SOURCES' includes configure substitution `@GLW_SOURCES@' configure.ac:96: and is referred to from `libGLw_la_SOURCES'; configure.ac:96: configure substitutions are not allowed in _SOURCES variables With automake, we can do this a lot cleaner with an AM_CONDITIONAL. Shortened version: configure.ac: AM_CONDITIONAL([ENABLE_MOTIF], [test $enable_motif = yes]) Makefile.am: libGLw_la_SOURCES = GLwDrawA.c libGLw_la_CFLAGS = $(GLW_CFLAGS) libGLw_la_LIBADD = $(GLW_LIBS) if ENABLE_MOTIF libGLw_la_SOURCES += GLwMDrawA.c libGLw_la_CFLAGS += $(MOTIF_CFLAGS) libGLw_la_LIBADD += $(MOTIF_LIBS) endif -- 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 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] g3dvl: check for existence of header/libs
On Jul 15, 2011 12:06 PM, Andy Furniss andy...@ukfsn.org wrote: Andy Furniss wrote: I have another problem though, vdpau-softpipe is not using my LD_LIBRARY_PATH so fails to find where my lvdpau is. As you can see from below r600 does use it and adds -L/home/andy/Src/Xorg-git/modular/lib and links OK. Maybe this doesn't come from LD_LIBRARY_PATH and instead it works by luck as my libdrm is in the same place - I guess it comes from pkgconfig as the r600 Makefile has - DRIVER_LIBS = $(shell pkg-config libdrm --libs) -lXfixes Yeah, that's he reason. You want to use LDFLAGS at build time. LD_LIBRARY_PATH is used at run time. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] g3dvl: check for existence of header/libs
2011/7/14 Christian König deathsim...@vodafone.de: Hello list, I'm about to commit the attached patches, they add checks that the correct development packages are installed before enabling the different state trackers. Since me and autoconf are in a fight for several years now please take a look and check that I'm not doing anything stupid. Those look fine except for some mixed tabs (configure.ac is pretty much 4 space indent with no tabs). It would be nice to get the build to actually use the flags you collect from PKG_CHECK_MODULES. Hmm, I guess the equivalent is done in the Makefile with $(shell pkg-config ...). Someday I'd like to fix all those so they're done once during configure. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] robust-tarballs branch (Was: Error building on Windows with SCons)
Hi Jose, On Sat, Jul 9, 2011 at 6:03 AM, Jose Fonseca jfons...@vmware.com wrote: I heard no concerns so I went ahead and made a branch where: - I removed GLUT - derived Mesa tarballs' file list from git ls-files. http://cgit.freedesktop.org/mesa/mesa/log/?h=robust-tarballs I've confirmed that both automake and scons+crossmingw32 build correctly on Linux. I'd like to merge to main if there are no objections. Having a brief look through the commits, it looks like a lot of nice cleanup. A couple comments. 26edecac589819f0d0efe2165ab748dbc4e53394: Using the variable DIRECTORY is a little confusing since it's a symlink. DIRLINK may be better. 34983337f9d7db984e9f0117808274106d262110: - src/mesa/depend is in EXTRA_FILES. This seems like something that shouldn't be shipped. - You're passing -x autogen.sh to not ship autogen.sh, but is that the only thing that shouldn't be disted? Any chance you could compare an old tarball to a new tarball and see if any unintended new files slipped in? - This might be for another commit, but it would be nice to move that to a separate variable. To start it could be hacky with the arguments embedded: IGNORE_FILES = \ -x autogen.sh \ -x otherunwantedfile - $(LIBNAME).zip should depend on manifest.txt Looks good otherwise, though. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] configure.ac: Make --without-gallium-drivers work as expected
On Wed, Jun 22, 2011 at 11:38 AM, Ian Romanick i...@freedesktop.org wrote: From: Ian Romanick ian.d.roman...@intel.com --- configure.ac | 6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index c9dd8a7..76736c0 100644 --- a/configure.ac +++ b/configure.ac @@ -562,6 +562,12 @@ AC_ARG_WITH([gallium-drivers], [with_gallium_drivers=$withval], [with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT]) +# Doing '--without-gallium-drivers' will set this variable to 'no'. Clear it +# here so that the script doesn't choke on an unknown driver name later. +if test x$with_gallium_drivers = xno; then + with_gallium_drivers='' +fi Nitpicky, but the other thing that would be nice is if bare --with-gallium-drivers becomes $GALLIUM_DRIVERS_DEFAULT. Could be: case $with_gallium_drivers in yes) with_gallium_drivers=$GALLIUM_DRIVERS_DEFAULT ;; no) with_gallium_drivers='' ;; esac Either way, good to catch this case. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Understanding GLX_INDIRECT_RENDERING (libOSMesa fails to link due to gl_dispatch_stub*)
On Tue, Jun 7, 2011 at 11:13 AM, Brian Paul bri...@vmware.com wrote: On 06/07/2011 11:26 AM, Jeremy Huddleston wrote: On Jun 7, 2011, at 1:01 PM, Jeremy Huddleston wrote: On Jun 7, 2011, at 12:01 PM, Jeremy Huddleston wrote: So what is the proper fix here? How should libOSMesa be getting built? Should libmesa.a be providing those stubs (rather than my change which put them in mesa/osmesa)? Should the stubs be getting exported by libGL? Should GetHistogramEXT be exported by libGL? Based on my understanding, it seems like we should bring these stubs into libmesa.a (and remove them from mesa/xlib). Does that sound right? Actually... I'm perplexed about another issue here... why is libOSMesa linking against both libglapi and libGL? It seems like the only things resolving into libGL are the stub symbols missing in libglapi. If we provide them in osmesa, why does libOSMesa need to link against libGL at all? Similarly, libOSMesa seems to build fine if I just don't include libglapi.a and let it resolve those calls into libGL (which it can re-export to provide the gl* entry points). This of course requires libGL to be glapi-aware (which glx/apple isn't yet). As is, including libglapi.a in libOSMesa and in libGL will result in two copies of libglapi existing in memory which seems like a recipe for disaster since there will be two different dispatch tables, etc. Perhaps this isn't a problem on systems with flat namespaces, but on darwin, it is. Ok, I see what is happening. configs/darwin bitrotted and included the -lGL, but other configs have since removed that. It looks like I should just remove -lGL from OSMESA_LIB_DEPS in addition to the other changes that I've already sent for osmesa.c It looks like -lGL is still done in default, beos, and aix ... so someone might want to update those as well... At one time, I had things set up so that one libGL.so contained both the GLX and OSMesa interfaces. An app could create a context of each time and freely switch between them with glX/OSMesa-MakeCurrent(). A while back this got changed so the OSMesa stuff lives in its own libOSMesa.so library. IIRC, it became really complicated with hidden symbol visibility to keep all the setups linking correctly. I'm sure there's a way to fix it, but it could be hairy. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: don't touch git_sha1.h if sha1 didn't change
On Sun, May 1, 2011 at 2:53 PM, Marcin Slusarz marcin.slus...@gmail.com wrote: Less recompiles... Good idea. Couple nits. --- bin/extract_git_sha1 | 8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index e6e6731..fc7bf85 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -1,10 +1,14 @@ #!/bin/sh -touch src/mesa/main/git_sha1.h Instead of moving the touch out to when there's no git, perhaps it would be better to just touch the file when it doesn't exist. [ -f src/mesa/main/git_sha1.h ] || touch src/mesa/main/git_sha1.h That way your later diff command won't complain on stdout that one of the files is missing on a fresh checkout. if which git /dev/null; then # Extract the 7-digit short SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in # src/mesa/main/version.c to put the GIT SHA1 in the GL_VERSION string. git log -n 1 --oneline |\ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 git-\1/' \ - src/mesa/main/git_sha1.h + src/mesa/main/git_sha1.h.tmp + if ! diff src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h /dev/null; then + mv src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h + fi I might suggest using cmp -s here since it's more suited to what we want: just says if the files are the same without having to figure out what's different. +else + touch src/mesa/main/git_sha1.h fi -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v2 1/2] mesa: don't touch git_sha1.h if sha1 didn't change
On May 2, 2011 11:08 AM, Marcin Slusarz marcin.slus...@gmail.com wrote: Less recompiles... --- bin/extract_git_sha1 | 10 -- src/mesa/main/.gitignore |1 + 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index e6e6731..5e635d4 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -1,10 +1,16 @@ #!/bin/sh -touch src/mesa/main/git_sha1.h +if [ ! -f src/mesa/main/git_sha1.h ]; then + touch src/mesa/main/git_sha1.h +fi + if which git /dev/null; then # Extract the 7-digit short SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in # src/mesa/main/version.c to put the GIT SHA1 in the GL_VERSION string. git log -n 1 --oneline |\ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 git-\1/' \ -src/mesa/main/git_sha1.h +src/mesa/main/git_sha1.h.tmp +if ! cmp -s src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h; then + mv src/mesa/main/git_sha1.h.tmp src/mesa/main/git_sha1.h +fi fi diff --git a/src/mesa/main/.gitignore b/src/mesa/main/.gitignore index e48030e..2575f44 100644 --- a/src/mesa/main/.gitignore +++ b/src/mesa/main/.gitignore @@ -3,3 +3,4 @@ api_exec_es2.c get_es1.c get_es2.c git_sha1.h +git_sha1.h.tmp -- 1.7.4.1 Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: don't call git if it's not git repository
On May 2, 2011 11:09 AM, Marcin Slusarz marcin.slus...@gmail.com wrote: --- bin/extract_git_sha1 |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/bin/extract_git_sha1 b/bin/extract_git_sha1 index 5e635d4..8283870 100755 --- a/bin/extract_git_sha1 +++ b/bin/extract_git_sha1 @@ -3,6 +3,10 @@ if [ ! -f src/mesa/main/git_sha1.h ]; then touch src/mesa/main/git_sha1.h fi +if [ ! -d .git ]; then + exit +fi + if which git /dev/null; then # Extract the 7-digit short SHA1 for the current HEAD, convert # it to a string, and wrap it in a #define. This is used in -- 1.7.4.1 Yeah this is needed for tarballs. Reviewed-by: Dan Nicholson dbn.li...@gmail.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] Fix config check that claims to test if CXX supports -fvisibility=hidden option to actually test the C++ compiler.
On Tue, Apr 26, 2011 at 5:00 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Looking at this bit of autofoolery, I notice that at the moment it is just checking if CC supports -fvisibility=hidden twice Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- configure.ac | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/configure.ac b/configure.ac index 3b05ca3..37ea5e7 100644 --- a/configure.ac +++ b/configure.ac @@ -170,8 +170,10 @@ if test x$GXX = xyes; then AC_MSG_CHECKING([whether $CXX supports -fvisibility=hidden]) VISIBILITY_CXXFLAGS=-fvisibility=hidden CXXFLAGS=$CXXFLAGS $VISIBILITY_CXXFLAGS + AC_LANG_PUSH([C++]) AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), [VISIBILITY_CXXFLAGS= ; AC_MSG_RESULT([no])]); + AC_LANG_POP([C++]) # Restore CXXFLAGS; VISIBILITY_CXXFLAGS are added to it where needed. CXXFLAGS=$save_CXXFLAGS I'm not super familiar with how AC_LANG_PROGRAM works, but this seems right as it should use whatever AC_LANG is. http://www.gnu.org/software/autoconf/manual/autoconf.html#Language-Choice http://www.gnu.org/software/autoconf/manual/autoconf.html#Writing-Test-Programs -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] Don't use -fvisibilty=hidden on cygwin
On Tue, Apr 26, 2011 at 5:00 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Using -fvisibility=hidden makes the current cygwin gcc emit a warning warning: visibility attribute not supported in this configuration; ignored for every single non-static symbol $ make clean make 21 | grep ignored | wc -l 6457 This is pretty annoying and makes it hard to spot other errors and warnings in the compiler output. It's not clear how to fix this. Possibly the correct solution is explicitly decorate all symbols with macros which annotate the expected visibility and evaluate to attribute(hidden/default) or dllexport depending on the target, as suggested at [1], but this would be a lot of work and misses the main advantage of -fvisibility=hidden (that you don't have to explicitly annotate everything :-)), so I guess we are supposed to know when -fvisibility isn't going to be useful and not use it. [1] http://gcc.gnu.org/wiki/Visibility Alternatively, the configuration check could be made more complex to avoid using this flag is the target isn't ELF or using the flag generates a warning You could add -Werror to the CFLAGS used for the visibility test since any host that's throwing warnings for something so simple probably has issues with visibility. Something like: diff --git a/configure.ac b/configure.ac index 8989c2b..ec662a3 100644 --- a/configure.ac +++ b/configure.ac @@ -152,7 +152,7 @@ if test x$GCC = xyes; then save_CFLAGS=$CFLAGS AC_MSG_CHECKING([whether $CC supports -fvisibility=hidden]) VISIBILITY_CFLAGS=-fvisibility=hidden -CFLAGS=$CFLAGS $VISIBILITY_CFLAGS +CFLAGS=$CFLAGS $VISIBILITY_CFLAGS -Werror AC_LINK_IFELSE([AC_LANG_PROGRAM()], AC_MSG_RESULT([yes]), [VISIBILITY_CFLAGS=; AC_MSG_RESULT([no])]); Does that do the right thing? -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] configure.ac: enable LLVM by default
On Fri, Apr 22, 2011 at 8:52 AM, Dan Nicholson dbn.li...@gmail.com wrote: On Thu, Apr 21, 2011 at 4:39 AM, Marek Olšák mar...@gmail.com wrote: OpenSUSE is (was?) shipping r300g with LLVM disabled. Can you believe it? Poor users with SWTCL chipsets... and bad reputation for us too. --- configure.ac | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index 8989c2b..8e9f73f 100644 --- a/configure.ac +++ b/configure.ac @@ -1687,10 +1687,10 @@ dnl Gallium LLVM dnl AC_ARG_ENABLE([gallium-llvm], [AS_HELP_STRING([--enable-gallium-llvm], - [build gallium LLVM support @:@default=disabled@:@])], + [build gallium LLVM support @:@default=enabled@:@])], [enable_gallium_llvm=$enableval], [enable_gallium_llvm=auto]) -if test x$enable_gallium_llvm = xyes; then +if test x$enable_gallium_llvm != xno; then if test x$LLVM_CONFIG != xno; then LLVM_VERSION=`$LLVM_CONFIG --version` LLVM_CFLAGS=`$LLVM_CONFIG --cppflags` Hit send a little too fast. This looks right, although the default is really auto and will silently continue if the user doesn't have LLVM. That's a little different than enabled. It would be nice for the user if configure errors when LLVM_CONFIG=no and enable_gallium_llvm=yes. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] libxml2 (python) dependency
On Mon, Apr 18, 2011 at 11:14 PM, Tilman Sauerbeck til...@code-monkey.de wrote: Ian Romanick [2011-04-18 17:12]: On 04/18/2011 04:48 PM, tom fogal wrote: Hey all, We recently became more aware of a dependency on python's libxml2 for building Mesa. We're not as proactive as we should be, but tend to upgrade Mesa every few releases; I think this was a jump from 7.8 to 7.10. Anyway, libxml2 is a bit arduous for us because it's not installed by default on Linux or Mac. On Linux, it's easy to grab via a package manager, but still does not exist by default on some distros. In general, non-standard dependencies are difficult because they make our (already very large) software stack more complex. Is the package truly needed? I think it's used to parse spec files and autogenerate trampolines or callbacks or something like that. Didn't we used to have plain text files for that? Any reason we can't go back to something simpler? Does code speak loud than words, here? :) We haven't used plain-text for years. What has changed is that the generated files are no longer tracked in source control. They are generated at compile time because anything else is just nuts. :) I know What about generating them at 'make dist' time, too...? That way the Python dependency would only hit developers, but not people building from proper release tarballs. I think this is a good idea, but it might be a little difficult with the mesa build machinery. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 2/2] mesa: Include GIT SHA1 in GL version string
On Thu, Mar 31, 2011 at 3:41 PM, Eric Anholt e...@anholt.net wrote:
On Thu, 31 Mar 2011 13:56:56 -0700, Corbin Simpson
mostawesomed...@gmail.com wrote:
On Thu, Mar 31, 2011 at 1:30 PM, Ian Romanick i...@freedesktop.org wrote:
From: Ian Romanick ian.d.roman...@intel.com
---
Makefile | 8
src/mesa/main/version.c | 7 ++-
2 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index a1ab65e..c85b903 100644
--- a/Makefile
+++ b/Makefile
@@ -5,7 +5,15 @@ TOP = .
SUBDIRS = src
+# The git command below generates an empty string when we're not
+# building in a GIT tree (i.e., building from a release tarball).
default: $(TOP)/configs/current
+ @touch src/mesa/main/git_sha1.h
+ @if which git /dev/null; then \
+ git log -n 1 --oneline |\
+ sed 's/^\([^ ]*\) .*/#define MESA_GIT_SHA1 \1/' \
+ src/mesa/main/git_sha1.h; \
+ fi
@for dir in $(SUBDIRS) ; do \
if [ -d $$dir ] ; then \
(cd $$dir $(MAKE)) || exit 1 ; \
diff --git a/src/mesa/main/version.c b/src/mesa/main/version.c
index c7a0d69..80fa0c2 100644
--- a/src/mesa/main/version.c
+++ b/src/mesa/main/version.c
@@ -25,6 +25,7 @@
#include imports.h
#include mtypes.h
#include version.h
+#include git_sha1.h
@@ -185,7 +186,11 @@ compute_version(struct gl_context *ctx)
ctx-VersionString = (char *) malloc(max);
if (ctx-VersionString) {
_mesa_snprintf(ctx-VersionString, max,
- %u.%u Mesa MESA_VERSION_STRING,
+ %u.%u Mesa MESA_VERSION_STRING
+#ifdef MESA_GIT_SHA1
+ ( MESA_GIT_SHA1 )
+#endif
+ ,
ctx-VersionMajor, ctx-VersionMinor);
}
}
--
1.7.4
Hmm, wouldn't the output of git describe be more useful?
That's what we talked about initially, but since we tag releases of the
stable branches, git describe of master says:
snb-magic-2692-gb3d1c77
which is some tag off master that we pushed last year.
I think krh knows the magic command, but git rev-list HEAD works here.
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 0/3] Only require libdrm if direct rendering is actually enabled
On Mon, Mar 14, 2011 at 5:23 PM, Brian Paul brian.e.p...@gmail.com wrote: On Mon, Mar 14, 2011 at 4:03 PM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: On 16/02/2011 15:44, Julien Cristau wrote: On Wed, Feb 16, 2011 at 15:11:34 +, Jon TURNEY wrote: At the moment, libGL cannot be built --with-driver=dri --disable-driglx-direct on platforms which don't have libdrm. --with-driver=dri is the only way to build a libGL which supports indirect rendering. This patch set makes libdrm only required if --enable-driglx-direct is used, and makes --disable-driglx-direct the default on cygwin and hurd. (this patch set combines patches from fd.o bugs #27840 and #29460, updated for the current git master) Jon TURNEY (1): Disable direct rendering on Cygwin Samuel Thibault (1): Only require libdrm if direct rendering is actually enabled. nobled (1): Disable direct rendering on GNU/Hurd For the series: Reviewed-by: Julien Cristau jcris...@debian.org Thanks, updated patches with tag added to follow. Can I apply for mesa commit access, since no-one seems to be particularly interested in picking up my patches? Sure, there's instructions on the website. I'll commit these tomorrow if there's no objection. They look OK to me but I'm not an autoconf expert. Yeah, sorry to Jon. I always mean to review these patches, but too much life always gets in the way. Jon has done a ton of fixes from building X on cygwin and definitely gets my backing for committing here. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Define GLX_USE_TLS when the user asks for TLS.
On Mon, Feb 21, 2011 at 9:11 PM, Chia-I Wu olva...@gmail.com wrote: On Mon, Feb 21, 2011 at 8:12 PM, Tom Fogal tfo...@sci.utah.edu wrote: From: Tom Fogal tfo...@alumni.unh.edu Without this, we do not actually respect the request for TLS. What is your setup? The macro should be defined as part of $(CFLAGS). It may not be a good practice as the variable is normally considered a user variable, but mesa does not quite support that. Yeah, that was an unfortunate thing that I propagated in the initial autoconf support because all the existing Makefiles used bare $(CFLAGS). It would be really good (although completely mind numbing) if someone would make a local CFLAGS (e.g. MESA_CFLAGS or LOCAL_CFLAGS or something) and add that into all the Makefiles where CFLAGS are used. Then we could alter configure.ac and configs/* to put Mesa's compiler settings in that variable and leave the user's CFLAGS settings alone. Same thing with CPPFLAGS and LDFLAGS if we hack on those (don't recall right now). -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH v3] mesa: Optionally build a dricore support library (v3)
On Sun, Feb 20, 2011 at 3:04 PM, Sedat Dilek sedat.di...@googlemail.com wrote: # LIBGL_DEBUG=verbose glxinfo 2/dev/null | grep -i opengl OpenGL vendor string: Mesa Project OpenGL renderer string: Software Rasterizer OpenGL version string: 2.1 Mesa 7.11-devel OpenGL shading language version string: 1.20 OpenGL extensions: Can you not redirect stderr to /dev/null? You're throwing away the verbose debugging info showing which dri driver it tries to open. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix --enable-shared-glapi configure option
On Wed, Feb 16, 2011 at 5:37 AM, Jon TURNEY jon.tur...@dronecode.org.uk wrote: Fix a typo which meant that --enable-shared-glapi didn't actually cause a shared glapi to be built Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk --- configure.ac | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index a5e9bfa..7c3ca4b 100644 --- a/configure.ac +++ b/configure.ac @@ -616,7 +616,7 @@ GALLIUM_DRIVERS_DIRS=softpipe failover galahad trace rbug noop identity GALLIUM_STATE_TRACKERS_DIRS= # build shared-glapi if enabled for OpenGL or if OpenGL ES is enabled -case x$enabled_shared_glapi$enable_gles1$enable_gles2 in +case x$enable_shared_glapi$enable_gles1$enable_gles2 in x*yes*) CORE_DIRS=$CORE_DIRS mapi/shared-glapi ;; Good catch. I guess people were getting this because they also had GLES enabled? -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Adding -enable-egl-dri2 option. Happy Chinese Spring Festival!
On Mon, Feb 07, 2011 at 01:58:19PM +0800, Arthur Zhu wrote: From 7f26f3b6692a8a8061c0d817388505d4190e88a0 Mon Sep 17 00:00:00 2001 From: Arthur Zhu xiaoxiaomuyusajiangt...@gmail.com Date: Mon, 7 Feb 2011 13:50:55 +0800 Subject: [PATCH] Adding --enable-egl-dri2-x11drm option. --- configure.ac | 34 +- 1 files changed, 21 insertions(+), 13 deletions(-) diff --git a/configure.ac b/configure.ac index 46938f4..18c2731 100644 --- a/configure.ac +++ b/configure.ac @@ -1091,6 +1091,20 @@ if test x$enable_egl = xno; then AC_MSG_ERROR([cannot enable OpenVG without EGL]) fi fi + +AC_ARG_ENABLE([egl-dri2-x11], +[AS_HELP_STRING([--enable-egl-dri2-x11], +[enable EGL egl-dri2-x11 driver, +Just omits libudev package checking. @:@default=disabled@:@])], +[enable_egl_dri2_x11=$enableval], +[enable_egl_dri2_x11=no]) + +AC_ARG_ENABLE([egl-dri2-drm], +[AS_HELP_STRING([--enable-egl-dri2-drm], +[enable EGL egl-dri2-drm driver. @:@default=disabled@:@])], +[enable_egl_dri2_drm=$enableval], +[enable_egl_dri2_drm=no]) + if test x$enable_egl = xyes; then SRC_DIRS=$SRC_DIRS egl EGL_LIB_DEPS=$DLOPEN_LIBS -lpthread @@ -1100,20 +1114,14 @@ if test x$enable_egl = xyes; then if test $mesa_driver = xlib -o $mesa_driver = dri; then EGL_DRIVERS_DIRS=glx fi - -if test $mesa_driver = dri; then +if test x$enable_egl_dri2_x11 = xyes -o x$enable_egl_dri2_drm = xyes -a $mesa_driver = dri; then It would be nice if you could wrap this into a newline. Like: if test x$enable_egl_dri2_x11 = xyes -o \ x$enable_egl_dri2_drm = xyes -a $mesa_driver = dri; then # build egl_dri2 when xcb-dri2 is available -PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], - [have_xcb_dri2=yes],[have_xcb_dri2=no]) -PKG_CHECK_MODULES([LIBUDEV], [libudev 150], - [have_libudev=yes],[have_libudev=no]) - -if test $have_xcb_dri2 = yes; then -EGL_DRIVER_DRI2=dri2 -DEFINES=$DEFINES -DHAVE_XCB_DRI2 -if test $have_libudev = yes; then -DEFINES=$DEFINES -DHAVE_LIBUDEV -fi +PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes]) +EGL_DRIVER_DRI2=dri2 +DEFINES=$DEFINES -DHAVE_XCB_DRI2 +if test x$enable_egl_dri2_drm = xyes; then +PKG_CHECK_MODULES([LIBUDEV], [libudev 150]) +DEFINES=$DEFINES -DHAVE_LIBUDEV fi fi Looks good to me otherwise. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Adding -enable-egl-dri2 option. Happy Chinese Spring Festival!
On Thu, Feb 3, 2011 at 5:26 AM, Arthur Zhu xiaoxiaomuyusajiangt...@gmail.com wrote: Thanks your good suggestions. Arthur From 7034307045f1d334e25adf7f739c5144a9afcb46 Mon Sep 17 00:00:00 2001 From: Arthur Zhu xiaoxiaomuyusajiangt...@gmail.com Date: Thu, 3 Feb 2011 21:12:04 +0800 Subject: [PATCH] Adding -enable-egl-dri2 option. --- configure.ac | 26 -- 1 files changed, 12 insertions(+), 14 deletions(-) diff --git a/configure.ac b/configure.ac index 46938f4..bd50767 100644 --- a/configure.ac +++ b/configure.ac @@ -1091,6 +1091,12 @@ if test x$enable_egl = xno; then AC_MSG_ERROR([cannot enable OpenVG without EGL]) fi fi + +AC_ARG_ENABLE([egl-dri2], + [AS_HELP_STRING([--enable-egl-dri2], + [enable EGL egl-dri2 driver @:@default=disabled@:@])], + [enable_egl_dri2=$enableval], + [enable_egl_dri2=no]) if test x$enable_egl = xyes; then SRC_DIRS=$SRC_DIRS egl EGL_LIB_DEPS=$DLOPEN_LIBS -lpthread @@ -1100,21 +1106,13 @@ if test x$enable_egl = xyes; then if test $mesa_driver = xlib -o $mesa_driver = dri; then EGL_DRIVERS_DIRS=glx fi - - if test $mesa_driver = dri; then + if test x$enable_egl_dri2 = xyes -a $mesa_driver = dri; then # build egl_dri2 when xcb-dri2 is available - PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], - [have_xcb_dri2=yes],[have_xcb_dri2=no]) - PKG_CHECK_MODULES([LIBUDEV], [libudev 150], - [have_libudev=yes],[have_libudev=no]) - - if test $have_xcb_dri2 = yes; then - EGL_DRIVER_DRI2=dri2 - DEFINES=$DEFINES -DHAVE_XCB_DRI2 - if test $have_libudev = yes; then - DEFINES=$DEFINES -DHAVE_LIBUDEV - fi - fi + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes]) + EGL_DRIVER_DRI2=dri2 + DEFINES=$DEFINES -DHAVE_XCB_DRI2 + PKG_CHECK_MODULES([LIBUDEV], [libudev 150]) + DEFINES=$DEFINES -DHAVE_LIBUDEV I didn't notice this the first time, but there are a couple changes of the semantics. Now if you say --enable-egl-dri2, configure will fail if you don't have XCB_DRI2. I think that's OK since the user has to explicitly enable the option. However, now the LIBUDEV dependency is unconditional, too. Is libudev required for egl-dri2? -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Adding -enable-egl-dri2 option. Happy Chinese Spring Festival!
On Tue, Feb 1, 2011 at 5:41 AM, Arthur Zhu xiaoxiaomuyusajiangt...@gmail.com wrote: From: Arthur Zhu arthur.zhuy...@gmail.com --- configure.ac | 29 +++-- 1 files changed, 15 insertions(+), 14 deletions(-) diff --git a/configure.ac b/configure.ac index 46938f4..8a429a7 100644 --- a/configure.ac +++ b/configure.ac @@ -1100,23 +1100,24 @@ if test x$enable_egl = xyes; then if test $mesa_driver = xlib -o $mesa_driver = dri; then EGL_DRIVERS_DIRS=glx fi + fi +fi +AC_ARG_ENABLE([egl-dri2], + [AS_HELP_STRING([--enable-egl-dri2], + [enable egl-dri2 driver. @:@default=disabled@:@])], + [enable_egl_dri2=$enableval], + [enable_egl_dri2=no]) +if test x$enable_egl_dri2 = xyes; then + if test $enable_static != yes; then if test $mesa_driver = dri; then # build egl_dri2 when xcb-dri2 is available - PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes], - [have_xcb_dri2=yes],[have_xcb_dri2=no]) - PKG_CHECK_MODULES([LIBUDEV], [libudev 150], - [have_libudev=yes],[have_libudev=no]) - - if test $have_xcb_dri2 = yes; then - EGL_DRIVER_DRI2=dri2 - DEFINES=$DEFINES -DHAVE_XCB_DRI2 - if test $have_libudev = yes; then - DEFINES=$DEFINES -DHAVE_LIBUDEV - fi - fi - fi - + PKG_CHECK_MODULES([XCB_DRI2], [x11-xcb xcb-dri2 xcb-xfixes]) + EGL_DRIVER_DRI2=dri2 + DEFINES=$DEFINES -DHAVE_XCB_DRI2 + PKG_CHECK_MODULES([LIBUDEV], [libudev 150]) + DEFINES=$DEFINES -DHAVE_LIBUDEV + fi EGL_DRIVERS_DIRS=$EGL_DRIVERS_DIRS $EGL_DRIVER_DRI2 fi fi This looks good, but I think it would be better if this stayed within the same conditional block as before. There's no sense checking for the egl_dri2 components if we're not using dri. So, I think you should just put the macro right before the x$enable_egl = xyes code. Something like this: AC_ARG_ENABLE([egl], [AS_HELP_STRING([--disable-egl], [disable EGL library @:@default=enabled@:@])], [enable_egl=$enableval], [enable_egl=yes]) sanitive --disable-egl input AC_ARG_ENABLE([egl-dri2], ...) if test x$enable_egl = xyes; then ... if x$enable_egl_dri2 = xyes test $mesa_driver = dri; then egl_dri2 checks fi ... fi Then the rest of the code is nearly unchanged in this case. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] util: require debug options to be separated by commas
On Wed, Jan 26, 2011 at 3:17 AM, José Fonseca jfons...@vmware.com wrote:
On Mon, 2011-01-24 at 20:52 -0800, Marek Olšák wrote:
Let's assume there are two options with names such that one is a substring
of another. Previously, if we only specified the longer one as a debug
option,
the shorter one would be considered specified as well (because of strstr).
This commit fixes it by checking that each option is surrounded by commas.
(a regexp would be nicer, but this is not a performance critical code)
---
src/gallium/auxiliary/util/u_debug.c | 39
+-
1 files changed, 38 insertions(+), 1 deletions(-)
diff --git a/src/gallium/auxiliary/util/u_debug.c
b/src/gallium/auxiliary/util/u_debug.c
index 59b7613..8cf7660 100644
--- a/src/gallium/auxiliary/util/u_debug.c
+++ b/src/gallium/auxiliary/util/u_debug.c
@@ -180,6 +180,43 @@ debug_get_num_option(const char *name, long dfault)
return result;
}
+static boolean str_has_option(const char *str, const char *name)
+{
+ const char *substr;
+
+ /* OPTION=all */
+ if (!util_strcmp(str, all)) {
+ return TRUE;
+ }
+
+ /* OPTION=name */
+ if (!util_strcmp(str, name)) {
+ return TRUE;
+ }
+
+ substr = util_strstr(str, name);
+
+ if (substr) {
+ unsigned name_len = strlen(name);
+
+ /* OPTION=name,... */
+ if (substr == str substr[name_len] == ',') {
+ return TRUE;
+ }
+
+ /* OPTION=...,name */
+ if (substr+name_len == str+strlen(str) substr[-1] == ',') {
+ return TRUE;
+ }
+
+ /* OPTION=...,name,... */
+ if (substr[-1] == ',' substr[name_len] == ',') {
+ return TRUE;
+ }
+ }
+
+ return FALSE;
+}
Marek,
The intention is good -- it would be nice to get options obeyed properly
--, but this will fail to find foo in OPTION=prefixfoosuffix,foo, so
it's replacing a bug with another.
I'd prefer we stop using strstr completely, and instead do:
1 - find the first ',' or '\0' in the string
2 - compare the previous characters with the option being searched, and
return TRUE if matches
3 - if it was ',' go back to 1, but starting from character after ','.
4 - otherwise return FALSE
It should be robust and almost the same amount of code.
You could also strtok pretty easily, but it can be a little
heavyweight if you're doing this repeatedly.
char *tmp, *tok;
tmp = strdup(str);
for (tok = strtok(tmp, ,); tok; tok = strtok(NULL, ,)) {
if (strcmp(tok, opt) == 0) {
free(tmp);
return TRUE;
}
}
free(tmp);
return FALSE;
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Export TLS support in gl.pc.
On Sun, Jan 9, 2011 at 2:32 PM, tom fogal tfo...@sci.utah.edu wrote: Ping! No NAKs in ~5 days and one explicit request (on xorg-devel): http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/17570 Okay for master, and (after settling) 7.10? Sorry, I was thinking of replying 5 days ago but then got distracted and forgot. :) The only thing I think is missing is the default fallback setting in configs/default. If you do the non-autoconf build, you'd end up with an empty field there. It might also be nice if we sanity checked the value we're going to put in gl.pc. Not a big deal, though. With the configs/default fix, Reviewed-by: Dan Nicholson dbn.li...@gmail.com -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Export TLS support in gl.pc.
On Mon, Jan 10, 2011 at 3:08 PM, tom fogal tfo...@sci.utah.edu wrote:
Dan Nicholson dbn.li...@gmail.com writes:
On Sun, Jan 9, 2011 at 2:32 PM, tom fogal tfo...@sci.utah.edu wrote:
Ping!
No NAKs in ~5 days and one explicit request (on xorg-devel):
=C2=A0http://permalink.gmane.org/gmane.comp.freedesktop.xorg.devel/17570
Okay for master, and (after settling) 7.10?
Sorry, I was thinking of replying 5 days ago but then got distracted
and forgot. :)
no worries, it happens!
The only thing I think is missing is the default fallback setting in
configs/default. If you do the non-autoconf build, you'd end up with
an empty field there.
Ooops, yep, good catch. I had already pushed, but I just now pushed a
one-liner to fix this (0e3ff159f950f7481af53506a8331476bc54c00f). It
looks to me like it defaults to off in those builds, so I used a `no'
default, but we rarely use those builds so please correct me if I've
got it wrong.
It might also be nice if we sanity checked the value we're going to
put in gl.pc. Not a big deal, though.
You mean something like:
if test ${var} != no -a ${var} != yes ; then
echo some error
exit 1
fi
? Where, then? That seems a little ucky to put into the makefiles, to
me. The alternative seems to be configure.ac, which wouldn't catch
non-ac builds, of course. Maybe you thought that was acceptable?
Yeah, in configure.ac, but then again it would only happen if you did
something like --enable-glx-tls=yeah. It's probably not worth caring.
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH Resend] mesa: Optionally build a dricore support library.
On Mon, Dec 20, 2010 at 8:34 PM, Christopher James Halse Rogers christopher.halse.rog...@canonical.com wrote: This an adds --enable-shared-dricore option to configure. When enabled, DRI modules will link against a shared copy of the common mesa routines rather than statically linking these. This saves about 30MB on disc with a full complement of classic DRI drivers. --- Resending as it seems to have been ignored the first time. We've applied this in Ubuntu as we are (as always) scrabbling for CD space on the LiveCDs, but Fedora had a similar patch in the dim distant past. This seems to be something that distros generally will be interested in. configs/autoconf.in | 8 - configs/default | 3 ++ configs/freebsd-dri | 4 ++- configs/linux-dri | 4 ++- configs/linux-dri-xcb | 4 ++- configs/linux-egl | 4 ++- configs/linux-indirect | 3 +- configure.ac | 32 +- src/glsl/Makefile | 20 ++- src/mesa/Makefile | 57 +++ src/mesa/drivers/dri/Makefile.template | 12 +++ src/mesa/drivers/osmesa/Makefile | 2 +- src/mesa/x86/read_rgba_span_x86.S | 8 13 files changed, 136 insertions(+), 25 deletions(-) diff --git a/configs/autoconf.in b/configs/autoconf.in index e2d70c6..37a137d 100644 --- a/configs/autoconf.in +++ b/configs/autoconf.in @@ -33,6 +33,8 @@ LLVM_LDFLAGS = @LLVM_LDFLAGS@ LLVM_LIBS = @LLVM_LIBS@ GLW_CFLAGS = @GLW_CFLAGS@ GLUT_CFLAGS = @GLUT_CFLAGS@ +DRI_CFLAGS = @DRI_CFLAGS@ +DRI_CXXFLAGS = @DRI_CXXFLAGS@ TALLOC_LIBS = @TALLOC_LIBS@ TALLOC_CFLAGS = @TALLOC_CFLAGS@ @@ -103,7 +105,10 @@ GALLIUM_AUXILIARIES = $(TOP)/src/gallium/auxiliary/libgallium.a GALLIUM_DRIVERS = $(foreach DIR,$(GALLIUM_DRIVERS_DIRS),$(TOP)/src/gallium/drivers/$(DIR)/lib$(DIR).a) # Driver specific build vars -DRI_DIRS = @DRI_DIRS@ +DRI_DIRS = @DRI_DIRS@ +DRICORE_GLSL_LIBS = @DRICORE_GLSL_LIBS@ +DRICORE_LIBS = @DRICORE_LIBS@ +DRICORE_LIB_DEPS = @DRICORE_LIB_DEPS@ EGL_PLATFORMS = @EGL_PLATFORMS@ EGL_CLIENT_APIS = @EGL_CLIENT_APIS@ @@ -131,6 +136,7 @@ GLESv2_LIB_DEPS = $(EXTRA_LIB_PATH) @GLESv2_LIB_DEPS@ VG_LIB_DEPS = $(EXTRA_LIB_PATH) @VG_LIB_DEPS@ # DRI dependencies +MESA_MODULES = @MESA_MODULES@ DRI_LIB_DEPS = $(EXTRA_LIB_PATH) @DRI_LIB_DEPS@ LIBDRM_CFLAGS = @LIBDRM_CFLAGS@ LIBDRM_LIB = @LIBDRM_LIBS@ diff --git a/configs/default b/configs/default index 0301345..1feeb97 100644 --- a/configs/default +++ b/configs/default @@ -85,6 +85,9 @@ VG_LIB_GLOB = $(VG_LIB_NAME)* TALLOC_LIBS = `pkg-config --libs talloc` TALLOC_CFLAGS = `pkg-config --cflags talloc` +DRI_CFLAGS = $(CFLAGS) +DRI_CXXFLAGS = $(CXXFLAGS) + # Optional assembly language optimization files for libGL MESA_ASM_SOURCES = diff --git a/configs/freebsd-dri b/configs/freebsd-dri index a4aa82e..23cf58a 100644 --- a/configs/freebsd-dri +++ b/configs/freebsd-dri @@ -30,9 +30,11 @@ ASM_SOURCES = MESA_ASM_SOURCES = # Library/program dependencies +MESA_MODULES = $(TOP)/src/mesa/libmesa.a + LIBDRM_CFLAGS = `pkg-config --cflags libdrm` LIBDRM_LIB = `pkg-config --libs libdrm` -DRI_LIB_DEPS = -L/usr/local/lib -lm -pthread -lexpat $(LIBDRM_LIB) +DRI_LIB_DEPS = $(MESA_MODULES) -L/usr/local/lib -lm -pthread -lexpat $(LIBDRM_LIB) GL_LIB_DEPS = -L/usr/local/lib -lX11 -lXext -lXxf86vm -lXdamage -lXfixes \ -lm -pthread $(LIBDRM_LIB) diff --git a/configs/linux-dri b/configs/linux-dri index 64fc407..caf0406 100644 --- a/configs/linux-dri +++ b/configs/linux-dri @@ -43,9 +43,11 @@ MESA_ASM_SOURCES = # Library/program dependencies EXTRA_LIB_PATH=-L/usr/X11R6/lib +MESA_MODULES = $(TOP)/src/mesa/libmesa.a + LIBDRM_CFLAGS = $(shell pkg-config --cflags libdrm) LIBDRM_LIB = $(shell pkg-config --libs libdrm) -DRI_LIB_DEPS = $(EXTRA_LIB_PATH) -lm -lpthread -lexpat -ldl -ltalloc $(LIBDRM_LIB) +DRI_LIB_DEPS = $(MESA_MODULES) $(EXTRA_LIB_PATH) -lm -lpthread -lexpat -ldl -ltalloc $(LIBDRM_LIB) GL_LIB_DEPS = $(EXTRA_LIB_PATH) -lX11 -lXext -lXxf86vm -lXdamage -lXfixes \ -lm -lpthread -ldl $(LIBDRM_LIB) diff --git a/configs/linux-dri-xcb b/configs/linux-dri-xcb index 8092a04..7518080 100644 --- a/configs/linux-dri-xcb +++ b/configs/linux-dri-xcb @@ -41,9 +41,11 @@ MESA_ASM_SOURCES = # Library/program dependencies EXTRA_LIB_PATH=$(shell pkg-config --libs-only-L x11) +MESA_MODULES = $(TOP)/src/mesa/libmesa.a + LIBDRM_CFLAGS = $(shell pkg-config --cflags libdrm) LIBDRM_LIB = $(shell pkg-config --libs libdrm) -DRI_LIB_DEPS = $(EXTRA_LIB_PATH) -lm -lpthread -lexpat -ldl $(LIBDRM_LIB) +DRI_LIB_DEPS = $(MESA_MODULES) $(EXTRA_LIB_PATH) -lm -lpthread -lexpat -ldl $(LIBDRM_LIB) GL_LIB_DEPS = $(EXTRA_LIB_PATH) -lX11
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Sun, Dec 12, 2010 at 7:19 PM, Jammy Zhou jammy.z...@linaro.org wrote: Hi Chia-I, Glad to see the fix goes so fast, thanks! I believe the direction is promising. And I am not familiar with the mapi module of mesa, so just one minor comment for the glapi: Fix OpenGL and OpenGL ES interop patch. For changes in configure.ac, please use \ instead of \', i.e, GLAPI_OWNER='$(GL_LIB)' - GLAPI_OWNER=$(GL_LIB). Sorry, but you do want single quotes here so that the variable doesn't get expanded until make does it. With double quotes, you'd be trying to run the shell function $(GL_LIB), which isn't a function. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] LLVM_CFLAGS
On Mon, Dec 6, 2010 at 9:15 AM, Brian Paul bri...@vmware.com wrote: On 12/05/2010 02:06 AM, Bob Gleitsmann wrote: Hello, Can someone explain the value of including this in mesa/src/gallium/Makefile.template: ifeq ($(MESA_LLVM),1) LIBRARY_DEFINES += $(LLVM_CFLAGS) endif ? This effectively adds the LLVM cflags to gcc compiles if LLVM is enabled. One side-effect of this is to include -O3 optimization no matter what, making debugging very difficult. Removing it seems to have no catastrophic effects (or even detectable ones). But maybe I am missing something. We need some of the LLVM C flags to get the -I path for headers, for example. I think we should use llvm-config --cppflags instead of --cflags. If you're using autoconf, try changing this line: LLVM_CFLAGS=`$LLVM_CONFIG --cflags` in configure.ac to use --cppflags instead. Does that help? I think the question is, what else is in llvm-config --cflags? If all that's needed is the include paths, then --cppflags would be sufficient. However, if there are macro definitions or compiler flags (e.g. -fomit-frame-pointer) in --cflags that are needed to properly use llvm, then I guess you need --cflags. This is really a bug in llvm, but the last time someone here tried to bring it up to the llvm people, it was dismissed. Here's that bug: http://llvm.org/bugs/show_bug.cgi?id=8220 There's some more in the mesa archives, but I can't find the thread now. Sadly, that bug became a discussion about pkg-config which was not what was intended. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Disappearing patches
On Tue, Oct 19, 2010 at 5:24 AM, Julien Cristau jcris...@debian.org wrote: On Tue, Oct 19, 2010 at 14:15:44 +0200, Thomas Hellstrom wrote: On 10/19/2010 01:55 PM, Julien Cristau wrote: On Tue, Oct 19, 2010 at 13:31:35 +0200, Thomas Hellstrom wrote: Hi! I've been trying to send a patch to mesa-dev a couple of times using git send-email, but the message never makes it to the list. Am I the only one having trouble with this? It did make it to the list, both times, as far as I can tell. http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003575.html http://lists.freedesktop.org/pipermail/mesa-dev/2010-October/003619.html Cheers, Julien Hmm, Thanks, You're obviously right. I wonder whether it might be the VMware spam filter automatically classifying my patches as crap when the list sends them back... It could be mailman deciding that since you're the sender you don't want them through the list? IIRC there's an option for that in the subscription preferences. Yeah, it's under the heading Receive your own posts to the list? There's also something about receiving a confirmation email that would be a big hammer to check if your posts are getting through. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cflags mess with llvm builds
On Sat, Sep 25, 2010 at 12:24 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Sep 24, 2010 at 11:36 PM, Xavier Chantry chantry.xav...@gmail.com wrote: On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri l...@luca-barbieri.com wrote: Yes, that used to happen for me too. Just edit llvm-config to remove the offending text and ideally file a bug on the LLVM bug tracker. looks like nobled did this for me : http://llvm.org/bugs/show_bug.cgi?id=8220 thanks :) The first answer is very negative and reports the bug as invalid. http://llvm.org/bugs/show_bug.cgi?id=8220#c1 The only suggestion is that custom flags could be appended. Another problem is indeed that mesa puts these llvm flags at the end, and the custom user CFLAGS first. Normally you do that because if the user has custom include paths, you want them to be at the beginning of the command line. It'd be nice if the llvm people could just use pkg-config instead of rolling their own config tool. I thought people had stopped doing that by now. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa symbol visibility
On Thu, Aug 12, 2010 at 2:07 AM, Kevin H. Hobbs hob...@ohiou.edu wrote:
On 08/11/2010 05:18 PM, tom fogal wrote:
Right. This is exactly why Mesa's name mangling exists.
You mean you haven't been mangling this whole time? I guess I haven't
been reading these mails closely enough.
-tom
It just seems perverse to have to use name mangling to deal with the
effects of adding -fvisibility=hidden.
Well, to be fair you were mostly getting lucky with a special case.
Like Ian says, trying to link with 2 different OpenGL libraries is a
little dicey. People building a DRI-enabled GL weren't offered this
possibility. Still, I feel bad that we didn't think of this issue at
the time.
A possible compromise here would be to put glX* stubs in OSMesa, but
_that_ seems perverse, too.
Maybe if name mangling really is required now the whole
--with-driver=xlib produces libGL.so and libOSMesa.so in one pas
should be disabled.
I'd kind of like to have OSMesa just be --{enable,disable}-osmesa
since it's completely standalone now. It would make some of the build
code less scary, too.
--
Dan
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] VTK Offscreen Segfaults
On Fri, Aug 6, 2010 at 2:20 PM, tom fogal tfo...@sci.utah.edu wrote: Kevin H. Hobbs hob...@ohiou.edu writes: On 08/06/2010 03:15 PM, tom fogal wrote: If you could build VTK with just a single GL library -- i.e. with just libOSMesa or just libGL, but not both -- and could reproduce the crash,= that would rule out my symbol collision theory. I am not sure how easy= that is, though... That was shockingly easy... sort of. I did my VTK build with both -DOPENGL_gl_LIBRARY:FILEPATH=3D/tmp/mesa/lib64/libOSMesa.so -DOSMESA_LIBRARY:FILEPATH=3D/tmp/mesa/lib64/libOSMesa.so and I left off -fvisibility=3Dhidden thinking that I want the symbols that are now included in libOSMesa.so to be available to VTK. Nah, the visibility thing only hides symbols that should be hidden anyway; i.e. the vbo symbols and the like. gl* will always be available regardless of the -fvisibility setting and regardless of which library is being built/used. and what do you know the test passed. Great! however I wanted to see if VTK is really built with only libOSMesa.so so I did : $ ldd ../VTK_Build/bin/RenderingCxxTests | grep mesa libOSMesa.so.7 = /tmp/mesa/lib64/libOSMesa.so.7 (0x7fa97ff4a000) libGL.so.1 = /tmp/mesa/lib64/libGL.so.1 (0x7fa97bc7a000) so it got pulled in somehow perhaps by libOSMesa.so itself? If I do : $ ldd ../mesa/lib64/libOSMesa.so | grep libGL.so libGL.so.1 = /usr/lib64/nvidia/libGL.so.1 (0x7f88ed2cf000) because libOSMesa.so needs libGL.so and I have the nvidia drivers in my dynamic linker path but VTK has an rpath set so... Yeah... hrm, I thought Dan's change got rid of that, but maybe I misunderstood it. Could you rm /tmp/mesa/lib64/libGL.so* before building VTK? My hunch is that VTK is linking it in anyway; maybe it stuck around in cmake's cache or something. What does all of this mean? Well, it does appear to be some type of symbol resolution/overloading issue. However it seems to be with internal Mesa symbols. Switching to a single library -- that is, putting OSMesaCreateContext, etc. into libGL directly, and getting rid of libOSMesa altogether -- seems like it would be the solution, but I imagine there's some reason that's not happening already. Let's ping Dan (added to the CC list), he knows more about this kind of thing than I do. Dan, have you been following this thread? The working theory is that there is a symbol in both libOSMesa and libGL. Something about the symbol existing in both is causing Badness during linking; seemingly innocuous changes cause Kevin's test program to jump into odd parts of Mesa (e.g. VBO code while doing initial matrix setup). The issue appears to be with internal symbols, but hidden symbol visibility isn't helping. Sorry, been busy lately. I haven't been following that closely, but it doesn't surprise me that there are duplicate symbols in OSMesa and GL. In fact, we set it up that way so that you could link to OSMesa without GL, get all the GL entrypoints, and not have to deal with visibility. So, I _think_ it should be unnecessary to link to GL when you're using OSMesa because it has all the GL symbols. If that's not true, we should fix the build so that you do get all the GL symbols and don't have link with it, too. So, sorry for not reading the whole thread, but is GL being linked because it's needed by the app, because pkg-config said so, or because the linker added it? -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa demos release version number
On Fri, Jun 18, 2010 at 9:00 AM, Jerome Glisse gli...@freedesktop.org wrote: Hi, Some distribution (like Fedora) are thinking about making new package for mesa demos but so far there is no release for it. Another issue is the versioning of mesa demos, i expect that mesa demos will be more stable than mesa thus i don't think we should follow mesa versioning but let it have it's own versioning (should we start with version 1.0 ?) If we can agree on versioning i can try to see if my kung-fu is good enough to do a release of mesa demo :) Well, if you start with the current mesa version, distro demo packages won't have to bump their epochs to upgrade. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson dbn.li...@gmail.com wrote: On Tue, Jun 15, 2010 at 3:32 PM, tom fogal tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Tue, Jun 15, 2010 at 12:55 PM, tom fogal tfo...@alumni.unh.edu wrote: Ian Romanick i...@freedesktop.org writes: If there are no objections, I will clean up the release notes and make the release tomorrow (Wednesday) morning. =C2=A0It looks like a few things got cherry-picked in the last week, so I'm assuming everything is in that people care about. OSMesa, which appears to get built by default --with-driver=3Dxlib, is broken on darwin w/ current 7.8 HEAD [1]: [snip -- undefined refs] Though I'm guessing this came from the symbol visibility changes (addition of -fvisibility=hidden), I don't have the time before tomorrow (or even this week :\) to take a real look. This is also the case on linux. https://bugs.freedesktop.org/show_bug.cgi?id=3D28305 Ahh, yeah, I guessed as much -- errors linking shlibs on OS X usually manifest as errors linking apps on Linux -- but I hadn't tested as much. I think the solution here is to stop linking OSMesa against GL and instead just pull in libmesa and friends all the time. In addition to avoiding the symbol visibility issues, it makes OSMesa more standalone, which is what people want anyway. Well, personally, I'd rather get glX* + OSMesa* + `normal' gl fqns in one lib, but I admit I'm probably the only one... I think it should be the same. The only difference is that you don't get file size savings because you have libmesa and friends built into both libGL and libOSMesa. But I've never really used OSMesa, so I could be dead wrong. I have a patch I was working on but haven't tested. I'll try to wrap it up tonight and shoot it over to you for a test. I'm attaching what I have right now if you want to play around with it. Thanks. The osmesa/Makefile changes didn't apply, so I did them manually.. which was very odd, because I don't see how the patch is different from what you sent. Anyway, the attached patch fixes the problem; I can build both xlib and standalone OSMesa on 10.5 w/ it. Cool. That diff was against master from like two months ago. I think that's all that's needed, but let me see if there's any other clean up that can be added. OK, I pushed the commit to master and 7.8 and added your Tested-by (I hope you don't mind). I think there's some definite build improvements with how osmesa is handled, but that's another story. This should be good for 7.8.2. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
On Wed, Jun 16, 2010 at 9:55 AM, tom fogal tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson dbn.li...@gmail.com wrote: I have a patch I was working on but haven't tested. I'll try to wrap it up tonight and shoot it over to you for a test. I'm attaching what I have right now if you want to play around with it. Thanks. The osmesa/Makefile changes didn't apply, so I did them manually.. which was very odd, because I don't see how the patch is different from what you sent. Anyway, the attached patch fixes the problem; I can build both xlib and standalone OSMesa on 10.5 w/ it. Cool. That diff was against master from like two months ago. I think that's all that's needed, but let me see if there's any other clean up that can be added. OK, I pushed the commit to master and 7.8 and added your Tested-by (I hope you don't mind). Not at all, sorry for not offering it up in the first place. I think there's some definite build improvements with how osmesa is handled, but that's another story. This should be good for 7.8.2. Release note? I only knew about this because a friend hit the issue. Oops. Noted now. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
On Wed, Jun 16, 2010 at 4:20 PM, Jeremy Huddleston jerem...@freedesktop.org wrote: Hey Tom, What version of OSX do you have? I hadn't pulled changes into my tree (http://cgit.freedesktop.org/~jeremyhu/mesa/log/?h=7.8) since the beginning of May, but I'm building that version just fine on Leopard and Snow Leopard with 'make darwin'. I haven't given the autoconf route a try for a while. I just merged origin/7.8 into my tree, and I just saw it successfully link libOSMesa: /bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \ -major 7 -minor 8 -patch 1 \ -install ../../../../lib \ -id /usr/X11/lib/libOSMesa.7.dylib \ -L../../../../lib -lGL osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a ../../../../src/glsl/cl/libglslcl.a ../../../../src/glsl/pp/libglslpp.a mklib: Making Darwin shared library: libOSMesa.7.8.dylib mklib: Installing libOSMesa.7.8.dylib libOSMesa.7.dylib libOSMesa.dylib in ../../../../lib Your LDFLAGS have: -lMesaGL osmesa.o whereas mine have: -lGL osmesa.o ../../../../src/mesa/libmesa.a ../../../../src/mesa/libglapi.a ../../../../src/glsl/cl/libglslcl.a which probably results from your use of the autoconf build system. A quick check shows the symbol you are looking for is in libmesa.a: ~/src/freedesktop/src/mesa (7.8) $ nm src/mesa/libmesa.a | grep mesa_make_current 05ce T __mesa_make_current 0004eca0 S __mesa_make_current.eh Right. In this case, the -lGL should be redundant since the reason OSMesa was linking to GL was just to not duplicate the internal libs (which you have here). Maybe you guys are using OSMesa differently than I think, though. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa 7.8.2 release?
On Tue, Jun 15, 2010 at 3:32 PM, tom fogal tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Tue, Jun 15, 2010 at 12:55 PM, tom fogal tfo...@alumni.unh.edu wrote: Ian Romanick i...@freedesktop.org writes: If there are no objections, I will clean up the release notes and make the release tomorrow (Wednesday) morning. =C2=A0It looks like a few things got cherry-picked in the last week, so I'm assuming everything is in that people care about. OSMesa, which appears to get built by default --with-driver=3Dxlib, is broken on darwin w/ current 7.8 HEAD [1]: [snip -- undefined refs] Though I'm guessing this came from the symbol visibility changes (addition of -fvisibility=hidden), I don't have the time before tomorrow (or even this week :\) to take a real look. This is also the case on linux. https://bugs.freedesktop.org/show_bug.cgi?id=3D28305 Ahh, yeah, I guessed as much -- errors linking shlibs on OS X usually manifest as errors linking apps on Linux -- but I hadn't tested as much. I think the solution here is to stop linking OSMesa against GL and instead just pull in libmesa and friends all the time. In addition to avoiding the symbol visibility issues, it makes OSMesa more standalone, which is what people want anyway. Well, personally, I'd rather get glX* + OSMesa* + `normal' gl fqns in one lib, but I admit I'm probably the only one... I think it should be the same. The only difference is that you don't get file size savings because you have libmesa and friends built into both libGL and libOSMesa. But I've never really used OSMesa, so I could be dead wrong. I have a patch I was working on but haven't tested. I'll try to wrap it up tonight and shoot it over to you for a test. I'm attaching what I have right now if you want to play around with it. Thanks. The osmesa/Makefile changes didn't apply, so I did them manually.. which was very odd, because I don't see how the patch is different from what you sent. Anyway, the attached patch fixes the problem; I can build both xlib and standalone OSMesa on 10.5 w/ it. Cool. That diff was against master from like two months ago. I think that's all that's needed, but let me see if there's any other clean up that can be added. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Drop glew from mesa
On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote: Jakob Bornecrantz wrote: On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Since we don't have any progs in mesa that uses glew anymore is it okay if we drop it? I have attached a patch which drops it its a bit big so I packed it. And here is the change thingy: configs/beos | 2 +- configs/darwin | 2 +- configs/default | 4 +- configs/freebsd-dri | 2 +- configs/linux-cell | 2 +- configs/linux-dri-xcb | 2 +- configs/linux-indirect | 2 +- configure.ac | 2 +- include/GL/glew.h |14435 include/GL/glxew.h | 1476 - include/GL/wglew.h | 1247 - src/SConscript | 1 - src/glew/LICENSE.txt | 73 - src/glew/Makefile | 54 - src/glew/SConscript | 69 - src/glew/glew.c |14320 --- src/glew/glewinfo.c | 8441 src/glew/visualinfo.c | 1173 18 files changed, 8 insertions(+), 41299 deletions(-) This got stuck in the moderation queue, resending without the patch. Looks good. But it would be handy to have glew in the mesa-demos tree so that we don't all have find/install the latest version. Yes. And glut, could we move glut to demos too? It would make building on windows easy again. glut might be something that deserves its own repo since some people use Kilgard's glut as their system glut. Requiring them to get that from a demos package seems a little odd. But splitting it out of the main mesa package seems nice, if not just for licensing reasons. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] RFC: Drop glew from mesa
On Tue, Jun 8, 2010 at 5:26 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: On Tue, Jun 8, 2010 at 3:51 PM, Brian Paul bri...@vmware.com wrote: Dan Nicholson wrote: On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca jfons...@vmware.com wrote: On Mon, 2010-06-07 at 07:36 -0700, Brian Paul wrote: Jakob Bornecrantz wrote: On Sat, Jun 5, 2010 at 6:03 PM, Jakob Bornecrantz wallbra...@gmail.com wrote: Since we don't have any progs in mesa that uses glew anymore is it okay if we drop it? I have attached a patch which drops it its a bit big so I packed it. And here is the change thingy: configs/beos | 2 +- configs/darwin | 2 +- configs/default | 4 +- configs/freebsd-dri | 2 +- configs/linux-cell | 2 +- configs/linux-dri-xcb | 2 +- configs/linux-indirect | 2 +- configure.ac | 2 +- include/GL/glew.h |14435 include/GL/glxew.h | 1476 - include/GL/wglew.h | 1247 - src/SConscript | 1 - src/glew/LICENSE.txt | 73 - src/glew/Makefile | 54 - src/glew/SConscript | 69 - src/glew/glew.c |14320 --- src/glew/glewinfo.c | 8441 src/glew/visualinfo.c | 1173 18 files changed, 8 insertions(+), 41299 deletions(-) This got stuck in the moderation queue, resending without the patch. Looks good. But it would be handy to have glew in the mesa-demos tree so that we don't all have find/install the latest version. Yes. And glut, could we move glut to demos too? It would make building on windows easy again. glut might be something that deserves its own repo since some people use Kilgard's glut as their system glut. Requiring them to get that from a demos package seems a little odd. But splitting it out of the main mesa package seems nice, if not just for licensing reasons. I'd be OK with that, but please don't remove it until glut is set up somewhere else, either in the demo repo or a new repo. I could move the glew sources into the demo tree but someone else will have to setup the automake stuff. I'm sure we can also make automake detect if glu and glut is installed and use the system ones instead of the ones shipping within the demos repo (also overridden with a option). What I'd like to do sooner or later is add *-uninstalled.pc files to the repo to support the I want to link the demos against the libGL in my mesa tree case that I figure lots of developers use. Then you could just do PKG_CONFIG_PATH=$HOME/src/mesa and the demo tree would never know the difference. Can we do the same to glu and glw? Giving --disable-glu --disable-glw --disable-glut as arguments to configure is getting old. Again, people/distros use these as their system glu and glw, so you can't just drop them from the mesa repo without moving them to an alternate location. However, we can easily make configure default to not building them. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [Mesa3d-dev] Separate demos repository
2010/6/4 Kristian Høgsberg k...@bitplanet.net: On Fri, Jun 4, 2010 at 7:13 AM, Keith Whitwell kei...@vmware.com wrote: ... checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether gcc and cc understand -c and -o together... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for DEMO... configure: error: Package requirements (gl) were not met: No package 'gl' found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables DEMO_CFLAGS and DEMO_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details. configure tries to locate the nvidia gl library using pkg-config, but nvidias library doesn't provide a .pc file (as far as I know, I don't have it here). I updated the configure script to fallback and try to look for GL.h and libGL.so manually when pkg-config fails. If it's not in the default location, I think you should be able to run configure as $ ./configure GL_CFLAGS=-I/opt/nvidia/include GL_LIBS=-L/opt/nvidia/libs -lGL and get it to pick up the libraries from there. The other hack obviously being that you create your own gl.pc file for nvidia and stuff it somewhere in PKG_CONFIG_PATH. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failure since May 6
On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs hob...@ohiou.edu wrote: All I really want is Mesa with OSMesa from the development repository as the reference library for my VTK and ParaView nightly test builds. ./configure --with-driver=xlib ? That will link libOSMesa to libGL, but that's what configs/linux-x86-64 is already doing (I think). If that's not working for you, please let me know. I tried to make this work correctly in the past, but personally use the dri drivers. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Build failure since May 6
On Mon, May 10, 2010 at 11:17 AM, tom fogal tfo...@alumni.unh.edu wrote: Dan Nicholson dbn.li...@gmail.com writes: On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs hob...@ohiou.edu wrote: All I really want is Mesa with OSMesa from the development repository as the reference library for my VTK and ParaView nightly test builds. ./configure --with-driver=xlib ? That will link libOSMesa to libGL, but that's what configs/linux-x86-64 is already doing (I think). If that's not working for you, please let me know. I tried to make this work correctly in the past, but personally use the dri drivers. We build like that already to satisfy VTK; I didn't realize OSMesa would appear in that library as well, so we did a second build for OSMesa. This would simplify things significantly. I will give it a try later today. The configure flag is --enable-gl-osmesa. The difference with --with-driver=osmesa is that you link to libGL instead of libmesa.a and friends, so you couldn't distribute libOSMesa.so standalone. See CORE_MESA in src/mesa/drivers/osmesa/Makefile. In some sense, it would still be nice to be able to work with a library that was only OSMesa. I imagine the additional code needed for libGL isn't all that much, though. I think the osmesa code is the same, it's just a matter of symbol resolution. The build machinery doesn't currently support gl + standalone osmesa in one pass, though. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] cant compile with llvmpipe enabled
On Mon, May 3, 2010 at 3:52 AM, yaiba.kurog...@interia.pl wrote: Hey. I get following error when try to compile mesa-git with --enable-gallium-llvm. g++ -Wl,--hash-style=gnu -Wl,--as-needed -L/usr/lib/llvm -lpthread -lffi -ldl -lm lp_test_format.o lp_test_main.o -o lp_test_format -Wl,--start-group -lXext -lXxf86vm -lXdamage -lXfixes -lX11-xcb -lX11 -lxcb-glx -lxcb -ldrm -lm -lpthread -ldl -L../../auxiliary/ -lgallium libllvmpipe.a -lLLVMBitWriter -lLLVMX86CodeGen -lLLVMX86Info -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMInterpreter -lLLVMJIT -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMCore -lLLVMSupport -lLLVMSystem -lstdc++ -Wl,--end-group ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_open': u_dl.c:(.text+0x21): undefined reference to `dlopen' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_get_proc_address': u_dl.c:(.text+0x50): undefined reference to `dlsym' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_close': u_dl.c:(.text+0x79): undefined reference to `dlclose' ../../auxiliary//libgallium.a(u_dl.o): In function `util_dl_error': u_dl.c:(.text+0xa3): undefined reference to `dlerror' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::LoadLibraryPermanently(char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar *)': (.text+0x32): undefined reference to `dlopen' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::LoadLibraryPermanently(char const*, std::basic_stringchar, std::char_traitschar, std::allocatorchar *)': (.text+0x8a): undefined reference to `dlerror' /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function `llvm::sys::DynamicLibrary::SearchForAddressOfSymbol(char const*)': (.text+0x1a2): undefined reference to `dlsym' /usr/lib/llvm/libLLVMSystem.a(Signals.o): In function `PrintStackTrace(void*)': (.text+0x74): undefined reference to `dladdr' /usr/lib/llvm/libLLVMSystem.a(Signals.o): In function `PrintStackTrace(void*)': (.text+0x1ea): undefined reference to `dladdr' collect2: ld returned 1 exit status make[4]: *** [lp_test_format] Error 1 something is missing in my system or something ??? Does the problem go away when you build without -Wl,--as-needed? If so, it seems like the libraries need to be reordered so the linker doesn't throw out -ldl. Otherwise, I don't know. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
