Re: [Mesa-dev] [PATCH] configure.ac: Disable GLX if OpenGL is not enabled
On Jan 31, 2013 2:51 AM, "Michel Dänzer" wrote: > > From: Michel Dänzer > > GLX uses mapi/glapi/libglapi.la, which is only built for OpenGL. > > Signed-off-by: Michel Dänzer > --- > 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 ___ 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
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
[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 --- 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
[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 --- 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
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 wrote: > On Sun, Dec 23, 2012 at 3:41 AM, Johannes Obermayr > wrote: >> Am Samstag, 22. Dezember 2012, 16:34:48 schrieben Sie: >>> On Sat, Dec 22, 2012 at 10:47 AM, Johannes Obermayr >>> wrote: >>> > Am Samstag, 22. Dezember 2012, 09:21:33 schrieb Matt Turner: >>> >> On Sat, Dec 22, 2012 at 9:16 AM, Johannes Obermayr >>> >> 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 >>
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 wrote: > Am Samstag, 22. Dezember 2012, 16:34:48 schrieben Sie: >> On Sat, Dec 22, 2012 at 10:47 AM, Johannes Obermayr >> wrote: >> > Am Samstag, 22. Dezember 2012, 09:21:33 schrieb Matt Turner: >> >> On Sat, Dec 22, 2012 at 9:16 AM, Johannes Obermayr >> >> 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 bu
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 wrote: > Am Samstag, 22. Dezember 2012, 09:21:33 schrieb Matt Turner: >> On Sat, Dec 22, 2012 at 9:16 AM, Johannes Obermayr >> 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 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
> ---
> 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" wrote: > > Signed-off-by: Emil Velikov Looks good. Reviewed-by: Dan Nicholson ___ 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" 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 > --- > 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" wrote: > > On Mon, Oct 8, 2012 at 8:27 PM, Daniel Stone 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 > > --- > > 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 Originally configure basically supported only GLX either through DRI or Xlib, so Xlib was basically required. Not so much nowadays. Reviewed-by: Dan Nicholson ___ 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 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 . Good catch. Reviewed-by: Dan Nicholson ___ 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 > > > > 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 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 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 ___ 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" 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 > +# > +# 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.freede
Re: [Mesa-dev] automake continued
On 6/13/12, Eric Anholt 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] [PATCH 01/19] automake: Don't warn on gmake portability issues.
On 6/13/12, Eric Anholt 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 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] [PATCH] Mesa: Fix a race in the build
On 6/13/12, Mike Frysinger wrote:
> On Wed, Jun 13, 2012 at 8:13 AM, Dan Nicholson wrote:
>
>> On Tue, Jun 12, 2012 at 3:52 PM, Mike Frysinger
>> wrote:
>> > On Tue, Jun 12, 2012 at 6:47 PM, Dan Nicholson
>> wrote:
>> >>
>> >> On 6/12/12, Stéphane Marchesin wrote:
>> >> > From: Mike Frysinger
>> >> >
>> >> > 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
___
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 wrote: > On Tue, Jun 12, 2012 at 6:47 PM, Dan Nicholson wrote: >> >> On 6/12/12, Stéphane Marchesin wrote: >> > From: Mike Frysinger >> > >> > 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/12/12, Stéphane Marchesin wrote: > From: Mike Frysinger > > 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... Reviewed-by: Dan Nicholson ___ 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 wrote: > On Mon, 11 Jun 2012 10:02:34 -0700 (PDT), Jose Fonseca > 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 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" 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" 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 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" 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 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 4/4] configure.ac: remove shared/static options
On Fri, Jan 20, 2012 at 12:57 PM, Matt Turner wrote: > On Sat, Jan 14, 2012 at 11:16 AM, Matt Turner wrote: >> now that libtool provides them. >> >> Signed-off-by: Matt Turner >> --- > > 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 -- 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.
s],
> [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
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 20/20] tests/glx: Add unit tests for GLX_ARB_create_context GLX protocol
2012/1/4 Ian Romanick : > On 01/04/2012 11:05 AM, Michel Dänzer wrote: >> >> On Mit, 2012-01-04 at 10:56 -0800, Ian Romanick wrote: >>> >>> On 01/04/2012 10:55 AM, Daniel Stone wrote: Hi, On 4 January 2012 18:45, Ian Romanick wrote: > > Okay, I looked back at your build output, and I think I see the > problem: > > * econf: updating Mesa-/bin/config.sub with > /usr/share/gnuconfig/config.sub > * econf: updating Mesa-/bin/config.guess with > /usr/share/gnuconfig/config.guess > ./configure --prefix=/usr --build=x86_64-pc-linux-gnu > [...] > > Since it's a raw GIT tree, this should be 'autogen.sh' instead of > 'configure'. The Makefile.in files are generated by autoreconf (run by > autogen.sh) and consumed by configure. Since they haven't been > generated, > configure can't find them and gets angry. The ebuild scripts need to > either > run ./autogen.sh or run 'autoreconf -v --install' before running > configure. > > I bet that will fix it, and I bet that's why only Gentoo users are > still > having problems. Can you give that a try? See immediately before that: >>> >>> Preparing source in >>> /var/tmp/portage/media-libs/mesa-/work/Mesa- ... Running eautoreconf in '/var/tmp/portage/media-libs/mesa-/work/Mesa-' ... Running aclocal ... [ok] Running autoconf ... [ok] >>> >>> Source prepared. >>> >>> >>> Okay. I give up. I have no clue why it's not working. Patches welcome. >>> :( >> >> >> It's not running automake (just like the Mesa toplevel Makefile >> isn't...). > > > Right... autoreconf does aclocal, autoconf, and automake all in one shot. > That makes sense. > > About adding automake to the toplevel Makefile, where should that go? It > seems like adding it to 'default' or similar will break the non-autotool > builds. Doing that so close before a release seems mean. Since the automake > business is only necessary for 'make check', would putting it in the 'check' > target be sufficient? Hi Ian, I'm a little busy at the moment, but just wanted to mention that the automake integration looks OK on a first glance. The problems being faced here seems to be gentoo's "eautoreconf" script. I'm guessing that since the toplevel Makefile is not Makefile.am, it doesn't think it needs to run automake. That's lame and it's the whole reason the regular autoreconf script exists in the first place. It can tell that you added AM_INIT_AUTOMAKE to configure.ac and therefore it needs to run automake. There's no "automake" to add in the toplevel Makefile. autogen.sh/autoreconf will do the right thing. That said, you could definitely hack in these changes without pulling in automake. -- 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
On Oct 12, 2011 1:30 PM, "tom fogal" 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
> >
> > 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/
On Sun, Sep 25, 2011 at 12:06 PM, Gaetan Nadon 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] [RFC PATCH] automake: add support to src/glsl/
On Sat, Sep 24, 2011 at 6:06 PM, Matt Turner wrote:
> Signed-off-by: Matt Turner
> ---
> 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/
Hi Matt,
On Sat, Sep 24, 2011 at 6:06 PM, Matt Turner wrote:
> Signed-off-by: Matt Turner
> ---
> 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] Removing GLw from the main Mesa repository
On Fri, Aug 5, 2011 at 7:25 AM, Benjamin Franzke 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] Removing GLw from the main Mesa repository
On Fri, Aug 5, 2011 at 6:45 AM, Brian Paul wrote: > On Thu, Aug 4, 2011 at 4:26 PM, Kenneth Graunke 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] [PATCH 01/15] mesa: Add toplevel Android.mk
On Thu, Aug 4, 2011 at 7:55 PM, Chad Versace wrote: > On 08/04/2011 04:17 PM, Jose Fonseca wrote: >> - Original Message - >>> On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace >>> 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 , CC: Chih-Wei Huang Signed-off-by: Chad Versace --- Android.mk | 66 android/mesa_local_vars.mk | 32 + 2 files changed, 98 insertions(+), 0 deletions(-) create mode 100644 Android.mk create mode 100644 android/mesa_local_vars.mk >>> >>> There's quite a bit of new build infrastructure here. What would it >>> take to fit this into either the existing autoconf support or add a >>> targeted configs/android? Duplicating a pile of make targets and >>> adding another way to configure/build mesa seems like it might not be >>> the best way to go. What are the current constraints that make >>> building mesa on android difficult? >> >> I agree. I'd prefer not have yet another build infrastructure in the mix, >> unless there's a very good reason. >> >> Jose > > I also agree. I would prefer to not add another build system to Mesa. We have > too many as it is. > > To address Dan's questions, the Android build cannot be fitted into autoconf > or > configs/android. I explored this option, and discovered that it was > impossible. > The Android build system is... well... interesting. Allow me to explain. > > The entirety of the Android project --- libc, webkit, the window manager, > *everything* --- exists in a single source tree [1]. And that source tree is > built with a single, non-recursive invocation of make. Every time I say that, > I > find it hard to believe myself, so I'll say it again: The entirety of the > Android OS, all core libraries and apps, are built with a single, > non-recursive > invocation of make. (The kernel is the special exception to this > all-encompassing build). The final build artifact is a bootable iso image. > > [1] http://android.git.kernel.org/ Looking at all those git repos, wouldn't this be more appropriate as an android project? platform/external/mesa or something? I haven't seen any Android.mk files show up in freetype or expat or anything like that. In the same way, mesa doesn't carry a debian folder even though that's how debian and ubuntu build mesa. Certainly if there are fixes to the existing build infrastructure that help get mesa built on android, that should be done, but I don't see why we should carry the android build bits in upstream mesa. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 01/15] mesa: Add toplevel Android.mk
On Thu, Aug 4, 2011 at 2:47 AM, Chad Versace 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 , > CC: Chih-Wei Huang > Signed-off-by: Chad Versace > --- > 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" 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 1/2] configure: allow C{,XX}FLAGS override
2011/7/14 Brian Paul : > On 07/13/2011 01:26 PM, Marcin Baczyński wrote: >> >> --- >> >> Without this patch CFLAGS=-fstrict-aliasing ./autogen.sh ... has no >> effect, >> as the flag is followed by -fno-strict-aliasing added by configure. >> >> configure.ac | 8 >> 1 files changed, 8 insertions(+), 0 deletions(-) >> >> diff --git a/configure.ac b/configure.ac >> index eace790..ef9f4b2 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -17,6 +17,10 @@ AC_INIT([Mesa],[mesa_version], >> AC_CONFIG_AUX_DIR([bin]) >> AC_CANONICAL_HOST >> >> +dnl Save user CFLAGS and CXXFLAGS so one can override the default ones >> +USER_CFLAGS="$CFLAGS" >> +USER_CXXFLAGS="$CXXFLAGS" >> + >> dnl Versions for external dependencies >> LIBDRM_REQUIRED=2.4.24 >> LIBDRM_RADEON_REQUIRED=2.4.24 >> @@ -1906,6 +1910,10 @@ 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/autoconf]) >> > > Looks OK to me, but an autoconf expert should probably verify that this is > the right fix. Anyone??? I _think_ it's OK, but I'm not sure why it's necessary. The way CFLAGS is constructed now it should have the user's CFLAGS prepended to the ones we add for mesa, e.g. -std c99, -fno-strict-aliasing. It's a little unfortunate that we don't have two separate variables: CFLAGS under total control of the user and MESA_CFLAGS (or something) that keeps the settings we make for mesa. But that shouldn't stop people from doing what Marcin is trying to do at configure time. Oh, now I see. Marcin wants his CFLAGS to follow the ones we set for mesa so he can override them. I guess I'm not really opposed to allowing that, but it's sort of a big hammer to overcome flags that (at some point) were decided they were needed to build mesa. Feel free to push it if you like. -- 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 : > 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 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-RFC] autoconf: add --enable-{dri,glx,osmesa}
On Sun, Jun 26, 2011 at 6:39 AM, Chia-I Wu wrote:
> From: Chia-I Wu
>
> The idea is that DRI driver, libGL and libOSMesa are libraries that can
> be independently enabled, yet --with-driver does not allow us to easily
> do that, if not impossible. This also matches what
> --enable-{egl,xorg,d3d1x} do for the respective libraries.
I haven't read this in any detail, but I definitely like the idea.
When I originally wrote all this, I struggled to coordinate DRI vs.
GLX, and I didn't really bother with the EGL code that was mostly
experimental. This is much more coherently structured.
> There are two libGL providers: Xlib-based and DRI-based. They cannot
> coexist. To be able to choose between them, --enable-xlib-glx is also
> added.
This is the only part that kind of bugs me. It seems to me that the
--enable-dri and --enable-xlib-glx options aren't really symmetric. I
believe you'd need this to be --enable-dri-glx to really act as a
provider. I can see why you didn't do that since dri is a "provider"
to many of the APIs and would require a lot more hacking of
configure.ac. Is my understanding of that correct? I'm not as familiar
with the newer non-GL Mesa components.
--
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 wrote: > From: Ian Romanick > > --- > 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 ___ 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 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 2/2] mesa: don't call git if it's not git repository
On May 2, 2011 11:09 AM, "Marcin Slusarz" 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 ___ 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" 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 ___ 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 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 2/2] Don't use -fvisibilty=hidden on cygwin
On Wed, Apr 27, 2011 at 4:06 AM, Jon TURNEY wrote:
> On 27/04/2011 11:39, Dan Nicholson wrote:
>> On Tue, Apr 26, 2011 at 5:00 AM, Jon TURNEY wrote:
>>> 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?
>
> Yes, this works, and in fact this was the approach I initially tried, and
> seems more elegant.
>
> However, I was concerned about false negatives. As far as I can tell, nothing
> guarantees that the test program compiled by AC_LANG_PROGRAM() compiles
> without warnings, only without errors, so using -Werror might cause this test
> to fail for reasons unrelated to -fvisibility.
>
> Looking at this a bit more, though, a bit of googling seems to indicate we
> wouldn't be the first to use this construction, so perhaps it's ok :-)
Yeah, I didn't say, but that's what I was worried about, too. On the
other hand, what we're trying to compile is a bunch of defines then:
int
main ()
{
;
return 0;
}
I'd hope we can do that without warnings. I'm fine if we don't feel
like messing with that now and would rather just blacklist cygwin.
--
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 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 2>&1 | 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] 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 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 > --- > 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 1/2] configure.ac: enable LLVM by default
On Fri, Apr 22, 2011 at 8:52 AM, Dan Nicholson wrote: > On Thu, Apr 21, 2011 at 4:39 AM, Marek Olšák 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] [PATCH 1/2] configure.ac: enable LLVM by default
On Thu, Apr 21, 2011 at 4:39 AM, Marek Olšák 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` > -- > 1.7.4.1 > > ___ > mesa-dev mailing list > mesa-dev@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/mesa-dev > ___ 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 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 wrote:
> On Thu, 31 Mar 2011 13:56:56 -0700, Corbin Simpson
> wrote:
>> On Thu, Mar 31, 2011 at 1:30 PM, Ian Romanick wrote:
>> > From: Ian Romanick
>> >
>> > ---
>> > 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 wrote: > On Mon, Mar 14, 2011 at 4:03 PM, Jon TURNEY > 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 >> >> 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] libtxc_dxtn 1.0.0 release
.On Sun, Mar 6, 2011 at 11:20 AM, Andy Furniss wrote: > Marek Olšák wrote: >> >> Hi, >> >> libtxc_dxtn has got new bug fixes in my private branch recently (e.g. Bug >> 24016 was fixed and some piglit tests too) and I thought it would be >> useful >> to make an announcement. >> >> I have tagged libtxc_dxtn 1.0.0 in my repository and it can be obtained >> via >> git from here: >> >> http://cgit.freedesktop.org/~mareko/libtxc_dxtn/ > > OK so I nay need to update something - but I don't usually have problems > with autogen and mesa/xorg. > > bash-3.2$ ./autogen.sh --prefix=/usr > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal > /usr/share/aclocal/xmms.m4:17: warning: underquoted definition of > XMMS_TEST_VERSION > /usr/share/aclocal/xmms.m4:17: run info '(automake)Extending aclocal' > /usr/share/aclocal/xmms.m4:17: or see > http://sources.redhat.com/automake/automake.html#Extending-aclocal > autoreconf: configure.ac: tracing > autoreconf: configure.ac: not using Libtool > autoreconf: running: /usr/bin/autoconf > autoreconf: configure.ac: not using Autoheader > autoreconf: running: automake --add-missing --copy --no-force > Makefile.am:1: Libtool library used but `LIBTOOL' is undefined > Makefile.am:1: The usual way to define `LIBTOOL' is to add > `AC_PROG_LIBTOOL' > Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. > Makefile.am:1: If `AC_PROG_LIBTOOL' is in `configure.ac', make sure > Makefile.am:1: its definition is in aclocal's search path. > autoreconf: automake failed with exit status: 1 > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking for gcc... gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > ./configure: line 3071: syntax error near unexpected token `disable-static' > ./configure: line 3071: `LT_INIT(disable-static)' You have a libtool older than 2.2. You can replace this with AC_PROG_LIBTOOL AC_DISABLE_STATIC Sooner or later enough distros will be on libtool-2.2+, but it's probably still too early for that. -- 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 wrote: > On Mon, Feb 21, 2011 at 8:12 PM, Tom Fogal wrote: >> From: Tom Fogal >> >> 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 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 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 > --- > 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 > Date: Mon, 7 Feb 2011 13:50:55 +0800 > Subject: [PATCH] Adding --enable-egl-dri2-x11&drm 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 wrote: > > Thanks your good suggestions. > > Arthur > > > From 7034307045f1d334e25adf7f739c5144a9afcb46 Mon Sep 17 00:00:00 2001 > From: Arthur Zhu > 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 wrote: > From: Arthur Zhu > > --- > 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]) AC_ARG_ENABLE([egl-dri2], ...) if test "x$enable_egl" = xyes; then ... if "x$enable_egl_dri2" = xyes && test "$mesa_driver" = dri; then 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 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 Mon, Jan 10, 2011 at 3:08 PM, tom fogal wrote:
> Dan Nicholson writes:
>> On Sun, Jan 9, 2011 at 2:32 PM, tom fogal 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] Export TLS support in gl.pc.
On Sun, Jan 9, 2011 at 2:32 PM, tom fogal 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 -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] TLS autodetection support in the X server
On Wed, Dec 22, 2010 at 3:18 PM, tom fogal wrote: > Alan Coopersmith writes: >> On 12/22/10 02:30 PM, tom fogal wrote: >> >> We generally don't copy macros from the autoconf-archive into >> xorg-macros, we just use them as is - adding *.m4 files to >> packages that need them (especially when it's just one or two >> packages, not most of X.Org's 200+ packages). See for instance, >> xserver/m4/ac_define_dir.m4 > > Ahh, okay. I missed that. > >> Is there any reason not to do that here? > > Nope. > >> Why should we add multiple levels of indirection to keep in sync? > > We shouldn't, I was just ignorant. I'll respin. > > ... and I have. Attached. Both against xorg/xserver this time. Tom, I thought the issue here was that mesa glx would get built with TLS, but xserver glx wouldn't. It seems like what you'd really want to do is get this macro into mesa so it could autodetect TLS capabilities and then use some value from mesa pkgconfig to detect how mesa glx was built. What do you think? -- 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 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_LI
Re: [Mesa-dev] [RFC] Solution to libGL.so and libGLES*.so mess
On Sun, Dec 12, 2010 at 7:19 PM, Jammy Zhou 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 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] [PATCH] autoconf: Better client API selection.
On Wed, Oct 27, 2010 at 3:30 AM, Chia-I Wu wrote: > From: Chia-I Wu > > Make autoconf decide the client APIs enabled first. Then when OpenGL > and OpenGL ES are disabled, there is no need to build src/mesa/; when > OpenGL is disabled, no $mesa_driver should be built. Finally, add > --enable-openvg to enable OpenVG. > > With these changes, an OpenVG only build can be configured with > > $ ./configure --disable-opengl --enable-openvg > > src/mesa, src/glsl, and src/glx will be skipped, which saves a great > deal of compilation time. > > And an OpenGL ES only build can be configured with > > $ ./configure --disable-opengl --enable-gles-overlay Just wanna say that I think this is great and the right way to go. I always wanted to do this but never found the time. I'll try to do a detailed review, but in case I don't get some time before you're ready to move on, Acked-by: Dan Nicholson ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] Fix usage of Python in Makefiles
On Mon, Oct 25, 2010 at 12:10 PM, Matthew William Cox wrote: > Hello list, > > There are still some places in the build system which directly call > python. This is an issue now that python3 has started to become the > default version, this is true on at least Arch Linux. The attached patch > fixes the build system to always use the PYTHON2 make variable together > with the PYTHON_FLAGS variables. This patch seems reasonable, but there are two logical changes here. Changing all the python to $(PYTHON) is a no brainer. However, removing the second -O from PYTHON_FLAGS is really a separate change. Can you explain that problem in more detail? It might also be more reasonable to just drop $(PYTHON_FLAGS) when using src/gallium/auxiliary/util/u_format_srgb.py so this isn't a global change. > Unfortunately, the autoconf side of things doesn't actually set these > variables to anything useful. config/autoconf.in sets PYTHON2=python > rather than having it be set as a result of running the configuration > script. At least having the Makefiles correctly use PYTHON2 means that > we can work around this by manually setting PYTHON2=python2 at the make > command invocation. Well, when I first added this python was only being used to generate the glapi code, which is stored in the repository. Really the only people who ever used it were the developers tinkering with glapi. Feel free to make a patch that gets the path to python. I think there's an AM_PYTHON macro or something like that. You just AC_PATH_PROG it, too. -- 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 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 Tue, Oct 5, 2010 at 7:56 AM, Xavier Chantry wrote: > On Sun, Sep 26, 2010 at 10:42 PM, Dan Nicholson wrote: >> >> 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. >> > > If llvm used pkg-config, we could then use the following pkg-config > options to solve the problem ? > --cflags-only-I output -I flags > --cflags-only-other output cflags not covered by the > cflags-only-I option > > So the gcc line could be like this : > $(pkg-config --cflags-only-other llvm) $CFLAGS $(pkg-config > --cflags-only-I llvm) > > or did you have something else in mind / are there other ways too ? You could do it that way, but the better way is just to be standard like everyone else. 1. Only output required flags to the user. If it's necessary to use -fomit-frame-pointer to use LLVM, so be it, but there's no reason -DNDEBUG should be in there. 2. Just use `pkg-config --cflags` like every other package and the pkg-config autoconf macros. I can't see any reason why they can't do that like the hundreds of other packages that export build flags. That way, we can just do: PKG_CHECK_MODULES([LLVM], [llvm]) vs. PKG_CHECK_EXISTS([llvm], [have_llvm=yes], [have_llvm=no]) if test $have_llvm = yes; then LLVM_CFLAGS_PRE=`$PKG_CONFIG --cflags-only-other llvm` LLVM_CFLAGS_POST=`$PKG_CONFIG --cflags-only-I llvm` LLVM_LIBS=`$PKG_CONFIG --libs llvm` fi with special handling in the Makefile. But if llvm doesn't want to play nice, then I guess that's what has to be done. -- 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 wrote: > On Fri, Sep 24, 2010 at 11:36 PM, Xavier Chantry > wrote: >> On Fri, Sep 24, 2010 at 3:15 PM, Luca Barbieri >> 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 (master): configs: Add -lstdc++ to default.
On Tue, Aug 24, 2010 at 6:35 AM, Brian Paul wrote: > On 08/24/2010 03:20 AM, Michel Dänzer wrote: >> >> On Don, 2010-08-19 at 18:11 -0700, Vinson Lee wrote: >>> >>> Module: Mesa >>> Branch: master >>> Commit: 9b7480cd95c2d1259e23bfb5549cefaa94ebaca1 >>> URL: >>> http://cgit.freedesktop.org/mesa/mesa/commit/?id=9b7480cd95c2d1259e23bfb5549cefaa94ebaca1 >>> >>> Author: Vinson Lee >>> Date: Thu Aug 19 18:09:24 2010 -0700 >>> >>> configs: Add -lstdc++ to default. >>> >>> This fixes the following error when trying to run glxinfo or glxgears >>> with swrast. >>> >>> undefined symbol: __cxa_pure_virtual >>> >>> --- >>> >>> configs/default | 2 +- >>> 1 files changed, 1 insertions(+), 1 deletions(-) >>> >>> diff --git a/configs/default b/configs/default >>> index 4f6334b..cdfa811 100644 >>> --- a/configs/default >>> +++ b/configs/default >>> @@ -116,7 +116,7 @@ EGL_CLIENT_APIS = $(GL_LIB) >>> >>> # Library dependencies >>> #EXTRA_LIB_PATH ?= >>> -GL_LIB_DEPS = $(EXTRA_LIB_PATH) -lX11 -lXext -lm -lpthread -ltalloc >>> +GL_LIB_DEPS = $(EXTRA_LIB_PATH) -lX11 -lXext -lm -lpthread -ltalloc >>> -lstdc++ >> >> If linking with libstdc++ can't be avoided, the standard solution is to >> link with g++ instead of using gcc -lstdc++, which doesn't work on all >> platforms. > > I missed this message/commit while I was away. > > The attached patch is how I would fix this problem. > > Vinson, can you try reverting your patch and trying this change? > > There may be other Makefiles where this change might be needed. Sorry I haven't been around much, but I believe it's definitely the preference to link with the c++ compiler instead of hardcoding -lstdc++. -- 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 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 wrote: > "Kevin H. Hobbs" 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] demos / glew configure bug
On Tue, Jul 13, 2010 at 7:42 AM, Brian Paul wrote: > On 07/13/2010 08:07 AM, Brian Paul wrote: >> >> I'm setting up the Mesa demos repo on a new system. autogen.sh fails >> because it can't find GLEW. I think autogen is looking for GLEW in >> /usr/include/GL/ and /usr/lib/libGLEW.a instead of using the copy of >> GLEW in the demos tree itself. >> >> Dan, can you fix that? >> >> >> $ ./autogen.sh >> [...] >> checking pkg-config is at least version 0.9.0... yes >> checking for GL... yes >> checking GL/glut.h usability... no >> checking GL/glut.h presence... no >> checking for GL/glut.h... no >> checking for glutInit in -lglut... no >> checking for GLEW... no >> checking GL/glew.h usability... no >> checking GL/glew.h presence... no >> checking for GL/glew.h... no >> configure: error: GLEW required > > Digging deeper... The issue is actually in the configure script (I think). > Even after copying libGLEW.a from Mesa 7.8.2 into /usr/lib/libGLEW.a (which > is the same as /usr/lib64/) configure is failing: > > [...] > checking pkg-config is at least version 0.9.0... yes > checking for GL... yes > checking GL/glut.h usability... no > checking GL/glut.h presence... no > checking for GL/glut.h... no > checking for glutInit in -lglut... no > checking for GLEW... no > checking GL/glew.h usability... yes > checking GL/glew.h presence... yes > checking for GL/glew.h... yes > checking for glewInit in -lGLEW... no > configure: error: GLEW required > > I wrote a test program that just calls glewInit() and compiled it with 'gcc > foo.c -lGLEW -lGL -o foo' and it worked fine. I'm traveling right now, but I believe the problem is that mesa does not install a glew.pc pkgconfig file. You can create one from the glu.pc example (or one of the others) and install it in /usr/lib/pkgconfig (for x86) or /usr/lib64/pkgconfig (for x86-64). The check for glew in the demos configure script would be something like: PKG_CHECK_MODULES([GLEW], [glew]) This would search for glew.pc and then the flags would be stored in GLEW_CFLAGS and GLEW_LIBS. I don't have a chance to fix this for another week or so, but it needs a little fixing on the mesa side for glew to be a fully installed library like gl or glu. -- 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 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 Wed, Jun 16, 2010 at 4:20 PM, Jeremy Huddleston 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 Wed, Jun 16, 2010 at 9:55 AM, tom fogal wrote: > Dan Nicholson writes: >> On Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson 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 Tue, Jun 15, 2010 at 4:26 PM, Dan Nicholson wrote: > On Tue, Jun 15, 2010 at 3:32 PM, tom fogal wrote: >> Dan Nicholson writes: >>> On Tue, Jun 15, 2010 at 12:55 PM, tom fogal wrote: >>> > Ian Romanick 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 Tue, Jun 15, 2010 at 3:32 PM, tom fogal wrote: > Dan Nicholson writes: >> On Tue, Jun 15, 2010 at 12:55 PM, tom fogal wrote: >> > Ian Romanick 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] Mesa 7.8.2 release?
On Tue, Jun 15, 2010 at 12:55 PM, tom fogal wrote: > Ian Romanick writes: >> > If there are no objections, I will clean up the release notes and >> > make the release tomorrow (Wednesday) morning. It 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=xlib, is > broken on darwin w/ current 7.8 HEAD [1]: > > /bin/sh ../../../../bin/mklib -o OSMesa -linker 'gcc' -ldflags '' \ > -major 7 -minor 8 -patch 1 \ > -install ../../../../lib \ > -id /Users/tfogal/sw/mesa-git/lib/libOSMesa.7.dylib \ > -L../../../../lib -lMesaGL osmesa.o > mklib: Making Darwin shared library: libOSMesa.7.8.dylib > Undefined symbols: > "__tnl_DestroyContext", referenced from: > _OSMesaDestroyContext in osmesa.o > "__mesa_make_current", referenced from: > _OSMesaMakeCurrent in osmesa.o > "__mesa_meta_free", referenced from: > _OSMesaDestroyContext in osmesa.o > "__mesa_problem", referenced from: > _compute_row_addresses in osmesa.o > _osmesa_renderbuffer_storage in osmesa.o > [snip] > > 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. > > So I'm attaching my build script && CC'ing Jeremy, in hopes we've > got some shared interests here. I'm not sure you care about OSMesa, > Jeremy, but IMHO we should at the very least disable it by default if > it's going to fail to link. > > -tom > > [1] a48edfad8ab95c331d768ba30a16ea51faec05da This is also the case on linux. https://bugs.freedesktop.org/show_bug.cgi?id=28305 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. 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. -- Dan standalone-osmesa.diff Description: Binary data ___ 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 6:13 PM, Jakob Bornecrantz wrote:
> On Wed, Jun 9, 2010 at 2:41 AM, Dan Nicholson wrote:
>> On Tue, Jun 8, 2010 at 5:26 PM, Jakob Bornecrantz
>> wrote:
>>> On Tue, Jun 8, 2010 at 3:51 PM, Brian Paul wrote:
>>>> Dan Nicholson wrote:
>>>>>
>>>>> On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca 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
>>>>>>>> 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.
>
> Or just use GL_CFLAGS=-I$HOME/src/mesa/include
> GL_LDFLAGS=-L$HOME/src/mesa/lib ./configure, but I guess the
> *-uninstalled.pc is less typing. Tho can .pc point to directories
> relative to the location of the .pc file?
I'm not 100% sure how it works, but here's an example:
http://git.gnome.org/browse/glib/tree/glib-2.0-uninstalled.pc.in
I think the "relative to .pc file" part is ${pcfiledir}, although
${pc_top_builddir} is confusing me.
> That will help for linking but not running without setting up
> LD_LIBRARY_PATH, tho I know automake can generate wrapper scripts if
> you use progname_LDADD = my_lib.la that picks up the right library at
> run time (see drm.git/tests/kmstest). I dunno if it will do the right
> thing with libraries added via AM_LDFLAGS, or ones external to the
> current build.
This is actually a libtool generated wrapper script. It's one of the
really nice features of libtool, and it usually works pretty well for
both internal and external libraries.
--
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 wrote: > On Tue, Jun 8, 2010 at 3:51 PM, Brian Paul wrote: >> Dan Nicholson wrote: >>> >>> On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca 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 >>>>>> 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] RFC: Drop glew from mesa
On Tue, Jun 8, 2010 at 3:07 AM, José Fonseca 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 >> > 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] [Mesa3d-dev] Separate demos repository
2010/6/4 Kristian Høgsberg : > On Fri, Jun 4, 2010 at 7:13 AM, Keith Whitwell 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 Thu, May 13, 2010 at 7:40 AM, Kevin H. Hobbs wrote: > On 05/12/2010 02:21 PM, Dan Nicholson wrote: >> >> >> Yeah, but you also have to stop it from being linked to libGL. Here's >> what I'd try on master, although I have tested it. You'll have to rerun >> autogen.sh. >> >> Dan >> > > I tried it and it tests as well with VTK as any recent build. Thanks. Well, you and Tom use a standalone osmesa. The only distro I looked at (fedora) uses a standalone osmesa. Maybe the build should just do that instead of trying to link to gl in some situations. It could certainly make the build a lot nicer. I'll try to put that into a formal patch since there's some other cleanup. -- 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 Wed, May 12, 2010 at 12:16:55PM -0400, Kevin H. Hobbs wrote: > On 05/12/2010 11:45 AM, tom fogal wrote: > > That said, I think Dan's idea of linking directly to libmesa is an > > easier way to solve your problem. > > > > Would that be done in : > > src/mesa/drivers/osmesa/Makefile > > by changing line 31 from > > CORE_MESA = > > to > > CORE_MESA = $(TOP)/src/mesa/libmesa.a > > ? Yeah, but you also have to stop it from being linked to libGL. Here's what I'd try on master, although I have tested it. You'll have to rerun autogen.sh. Dan diff --git a/configure.ac b/configure.ac index c40c842..34615e8 100644 --- a/configure.ac +++ b/configure.ac @@ -968,8 +968,8 @@ x16|x32) esac AC_SUBST([OSMESA_LIB]) -case "$mesa_driver" in -osmesa) +case "$DRIVER_DIRS" in +*osmesa*) # only link libraries with osmesa if shared if test "$enable_static" = no; then OSMESA_LIB_DEPS="-lm -lpthread $SELINUX_LIBS $DLOPEN_LIBS" @@ -979,19 +979,7 @@ osmesa) OSMESA_MESA_DEPS="" OSMESA_PC_LIB_PRIV="-lm -lpthread $SELINUX_LIBS $DLOPEN_LIBS" ;; -*) -# Link OSMesa to libGL otherwise -OSMESA_LIB_DEPS="" -# only link libraries with osmesa if shared -if test "$enable_static" = no; then -OSMESA_MESA_DEPS='-l$(GL_LIB)' -else -OSMESA_MESA_DEPS="" -fi -OSMESA_PC_REQ="gl" -;; esac -OSMESA_PC_LIB_PRIV="$OSMESA_PC_LIB_PRIV" AC_SUBST([OSMESA_LIB_DEPS]) AC_SUBST([OSMESA_MESA_DEPS]) AC_SUBST([OSMESA_PC_REQ]) diff --git a/src/mesa/drivers/osmesa/Makefile b/src/mesa/drivers/osmesa/Makefile index ea49a89..c6b4a04 100644 --- a/src/mesa/drivers/osmesa/Makefile +++ b/src/mesa/drivers/osmesa/Makefile @@ -20,17 +20,11 @@ INCLUDE_DIRS = \ -I$(TOP)/src/mesa \ -I$(TOP)/src/mesa/main -# Standalone osmesa needs to be linked with core Mesa APIs -ifeq ($(DRIVER_DIRS), osmesa) CORE_MESA = \ $(TOP)/src/mesa/libmesa.a \ $(TOP)/src/mapi/glapi/libglapi.a \ $(TOP)/src/glsl/cl/libglslcl.a \ $(TOP)/src/glsl/pp/libglslpp.a -else -CORE_MESA = -endif - .c.o: $(CC) -c $(INCLUDE_DIRS) $(CFLAGS) $< -o $@ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] OSMesa/libGL (was: Build failure since May 6)
On Mon, May 10, 2010 at 6:54 PM, tom fogal wrote:
> Dan Nicholson writes:
>> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs 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.
>
> Doesn't look like it's happening at present:
>
> �...@shigeru lib $ ls
> libMesaGL.so libMesaGL.so.1.5.070500 libOSMesa.so.7 pkgconfig
> libMesaGL.so.1 libOSMesa.so libOSMesa.so.7.5.0
> �...@shigeru lib $ nm -AC *.so | grep OSMesaMakeCurr
> libOSMesa.so:00011d99 T OSMesaMakeCurrent
> �...@shigeru lib $ ldd libMesaGL.so.1.5.070500
> linux-vdso.so.1 => (0x7fffe000)
> libX11.so.6 => /usr/lib/libX11.so.6 (0x7f7c12283000)
> libXext.so.6 => /usr/lib/libXext.so.6 (0x7f7c12072000)
> libm.so.6 => /lib/libm.so.6 (0x7f7c11dee000)
> libpthread.so.0 => /lib/libpthread.so.0 (0x7f7c11bd2000)
> libc.so.6 => /lib/libc.so.6 (0x7f7c1187f000)
> libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0x7f7c1167d000)
> libxcb.so.1 => /usr/lib/libxcb.so.1 (0x7f7c11461000)
> libdl.so.2 => /lib/libdl.so.2 (0x7f7c1125d000)
> libXau.so.6 => /usr/lib/libXau.so.6 (0x7f7c1105a000)
> /lib64/ld-linux-x86-64.so.2 (0x7f7c12beb000)
> libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x7f7c10e55000)
>
> "MesaGL" is just Mesa's "GL"; we rename it to avoid ambiguity. Our
> configure line is:
Well, it's OSMesa -> GL. But renaming GL -> MesaGL could cause a
problem since the linker doesn't know you've done that. Have you
considered overriding the name during the build so all the parts are
aware of it? Something like "make GL_LIB=MesaGL".
> ./configure \
> CC="${C_COMPILER}" \
> CXX="${CXX_COMPILER}" \
> CFLAGS="${CFLAGS} ${AIX_MESA_CFLAGS} -DUSE_MGL_NAMESPACE" \
> CXXFLAGS="${CXXFLAGS} -DUSE_MGL_NAMESPACE" \
> --prefix=${PF} \
> --without-demos \
> --disable-gallium \
> --with-driver=xlib \
> --enable-gl-osmesa \
> --disable-glw \
> --disable-glu \
> --disable-egl
>
> I tried both Mesa 7.5 and Mesa 7.8.1.
Kevin's post that default symbol visibility hidden breaks things might
be a showstopper anyway.
--
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 12:51 PM, Kevin H. Hobbs wrote: > On 05/10/2010 03:25 PM, Kevin H. Hobbs wrote: >> >> >> I really do not understand this missing symbol business since : >> >> >> $ nm mesa/lib/libGL.so | grep _mesa_free_context_data >> 00078030 t _mesa_free_context_data >> >> $ nm /opt/Mesa-7.8.1/lib64/libGL.so | grep _mesa_free_context_data >> 00092bc0 T _mesa_free_context_data >> > > Well there is a difference! Uppercase is global lower case is local. > > The mesa/configs/linux-x86-64 target makes this symbol global while the > auto tools configuration makes this symbol local... I guess this is because configure adds -fvisibility=hidden to the CFLAGS. Maybe we should always build osmesa against the internal static libraries instead of against libGL. -- 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 wrote: > Dan Nicholson writes: >> On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs 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] Build failure since May 6
On Mon, May 10, 2010 at 10:08 AM, Kevin H. Hobbs 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] [RFC] Convert mesa to automake/libtool
On Tue, May 4, 2010 at 5:34 AM, Ben Gamari wrote: > On Sun, May 2, 2010 at 12:46 PM, Dan Nicholson wrote: >> Brian, >> >> I'm putting forward this request completely understanding your >> position why you don't want automake and libtool in your project. >> However, I think that mesa has outgrown the static Makefiles approach >> for a number of reasons. For a project that's grown to the complexity >> of mesa, I believe you need something that is more flexible and robust >> than the current system can provide. Eric (and I think Corbin, too) >> has a branch adding automake and libtool to the mesa repo. >> >> http://cgit.freedesktop.org/~anholt/mesa/log/?h=automake >> >> I haven't looked at it in detail, but I know Eric knows what he's >> doing as he's maintained many of the autotooled xorg modules. Here are >> some of the pros and cons I see to making this change. >> > > > > Hey all, > > As a casual follower of Mesa, I too have been bitten bad builds on more than a > few occassions. That being said, Autotools makes me cringe and certainly makes > the build system less transparent to the end user. It seems that there is an > assumption that there exists only two options underlying this discussion: > Automakes, or what we have. I'm quite surprised that nobody has considered the > possibility of adopting a standard non-recursive makefile structure, as is > used > in, say, Keith Packard's notmuch[1] project. 1. Mesa is already basically doing this, but just in a poor way because everything has to be reimplemented since it's rolling it's own build system instead of leveraging an existing, supported one. 2. The scope of the mesa project and the number of optional pieces blows notmuch out of the water. If this were a small project, I might agree, but the main reason we've gotten to this point is because mesa has outgrown it's hand rolled system. > I recently reworked the build system of an internal piece of scientific > computing software with a notmuch-inspired makefile structure and the results > have been fantastic. The build is much faster, the makefiles are clearer (in > most cases nothing more than lists of rules), and the build integrity is > guaranteed (up to the quality of the prerequisite lists). Moreover, I was > quite > surprised by how well suited Make was to this style of build system. When one > adds a few features of GNU Make (per-target variables), the result is quite > impressive. I can only think of one mainstream project that uses GNU Make exclusively with consistently good results, and that's the linux kernel. And the reason why is because they have a maintainer (H. Peter Anvin) dedicated to the Kbuild system. As one of the people who has spent time maintaining the mesa build system, I can tell you that it is not nearly of that quality level. The last project I played around with that had a hand-rolled system was libdvdread. The way it worked was that things would break and then they would be reimplemented exactly as the autotools did it. And that's what I end up doing when I fix mesa build bugs. I spend a bunch of time figuring out where things went wrong and then I fix them just like automake would do it because they already solved that problem years ago. However, if the automake plan is nak'd, purely GNU make with all the features would be my next suggestion. >> Pros: >> * AM_CONDITIONAL provides a clean way to separate optional parts of >> the build. The way that optional components are handled right now is >> pretty fragile and basically amounts to having lists of subdirectories >> being correct in the config file. > > I don't see what's wrong with the ifdef directive. This seems like the right > way to deal with this in fact. Mesa is currently supposed to be using portable make features. Like I said, this would be my next suggestion, though. >> * For all mklib's simplicity, it is inconsistent between platforms, >> doesn't handle errors and provides only a scant amount of the features >> that libtool does. Libtool provides a robust and well tested means to >> generate libraries that handles nearly all the gory details about >> generating working binaries on many platforms. I don't think anyone >> working on mklib can claim to have the same type of knowledge about >> platforms and toolchains as the libtool developers. > > There's no reason why libtool requires autotools. This could be easily > integrated into a custom build system if need be. Have you ever actually seen anyone do that? I know of one project (libacl/libattr), and it was broken in a lot of ways. It's even discouraged by upstream. http://www.gnu.o
Re: [Mesa-dev] [RFC] Convert mesa to automake/libtool
On Mon, May 3, 2010 at 2:04 PM, Brian Paul wrote: > Dan Nicholson wrote: >> >> Brian, >> >> I'm putting forward this request completely understanding your >> position why you don't want automake and libtool in your project. >> However, I think that mesa has outgrown the static Makefiles approach >> for a number of reasons. For a project that's grown to the complexity >> of mesa, I believe you need something that is more flexible and robust >> than the current system can provide. Eric (and I think Corbin, too) >> has a branch adding automake and libtool to the mesa repo. >> >> http://cgit.freedesktop.org/~anholt/mesa/log/?h=automake >> >> I haven't looked at it in detail, but I know Eric knows what he's >> doing as he's maintained many of the autotooled xorg modules. Here are >> some of the pros and cons I see to making this change. >> >> Pros: >> * AM_CONDITIONAL provides a clean way to separate optional parts of >> the build. The way that optional components are handled right now is >> pretty fragile and basically amounts to having lists of subdirectories >> being correct in the config file. >> >> * For all mklib's simplicity, it is inconsistent between platforms, >> doesn't handle errors and provides only a scant amount of the features >> that libtool does. Libtool provides a robust and well tested means to >> generate libraries that handles nearly all the gory details about >> generating working binaries on many platforms. I don't think anyone >> working on mklib can claim to have the same type of knowledge about >> platforms and toolchains as the libtool developers. >> >> * Consistency in build commands for free from automake. Right now we >> have the compiling and linking commands repeated throughout the tree >> and they're typically out of sync. I've tried to keep them in sync >> before and it was a lot of effort. With automake all you really need >> to do is tell it the CFLAGS and LIBS to use and it'll take care of the >> rest. >> >> * Parallel make jobs just work. I've fixed so many of these race >> condition bugs, but they'd all just go away using automake. It has all >> the goop built in that people usually never think about. >> >> * Well defined distribution for tarballs. The top-level Makefile does >> the job, but automake can make this a lot easier and more robust. It >> would also be simple to handle the generated files while also >> requiring they be included in the tarball. >> >> * Fast source dependencies without external tools. The makedepend >> route works, but automake handles this in a faster, more robust and >> safer manner. We get a lot of people posting to the mailing list about >> build errors were the solution is "make realclean". This would solve a >> lot of those issues. >> >> * Mindshare from xorg autotools. Many of the people here have and do >> work with the autotools via xorg, so it's not like this is a >> completely foreign beast. >> >> * Moves the burden of build tool knowledge onto someone else. I don't >> think anyone here wants to become an expert on compilers, linkers and >> ABI for multiple platforms. It become a lot easier when you toss >> things off to libtool where people are actually spending their time >> caring about them. >> >> * Extensive documentation available, unlike the current system which >> is pretty much ad hoc. >> >> http://www.gnu.org/software/autoconf/manual/autoconf.html >> http://www.gnu.org/software/automake/manual/automake.html >> http://www.gnu.org/software/libtool/manual/libtool.html >> http://sourceware.org/autobook/autobook/autobook.html >> >> Cons: >> * The abstracted nature of automake causes build debugging to be >> difficult. This requires you to train your brain not to look at the >> generated Makefile, but still it can be difficult. Fortunately, many >> of the build bugs we see today in Mesa would go away with automake. >> >> * Using libtool means that you can't quickly hack around a fix for >> some platform. Fortunately, libtool is a lot more stable these days on >> common platforms. >> >> * The maintainer (you) doesn't like it. Not much I can suggest here >> besides that it gets a lot easier the more you deal with it. And I'd >> be happy to help you out of any jams. For xorg, Peter Hutterer has >> asked me to solve a bunch of these problems, and I can't remember the >> last time we couldn't get something f
Re: [Mesa-dev] cant compile with llvmpipe enabled
On Mon, May 3, 2010 at 3:52 AM, 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_string, std::allocator >*)': > (.text+0x32): undefined reference to `dlopen' > /usr/lib/llvm/libLLVMSystem.a(DynamicLibrary.o): In function > `llvm::sys::DynamicLibrary::LoadLibraryPermanently(char const*, > std::basic_string, std::allocator >*)': > (.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
[Mesa-dev] [RFC] Convert mesa to automake/libtool
Brian, I'm putting forward this request completely understanding your position why you don't want automake and libtool in your project. However, I think that mesa has outgrown the static Makefiles approach for a number of reasons. For a project that's grown to the complexity of mesa, I believe you need something that is more flexible and robust than the current system can provide. Eric (and I think Corbin, too) has a branch adding automake and libtool to the mesa repo. http://cgit.freedesktop.org/~anholt/mesa/log/?h=automake I haven't looked at it in detail, but I know Eric knows what he's doing as he's maintained many of the autotooled xorg modules. Here are some of the pros and cons I see to making this change. Pros: * AM_CONDITIONAL provides a clean way to separate optional parts of the build. The way that optional components are handled right now is pretty fragile and basically amounts to having lists of subdirectories being correct in the config file. * For all mklib's simplicity, it is inconsistent between platforms, doesn't handle errors and provides only a scant amount of the features that libtool does. Libtool provides a robust and well tested means to generate libraries that handles nearly all the gory details about generating working binaries on many platforms. I don't think anyone working on mklib can claim to have the same type of knowledge about platforms and toolchains as the libtool developers. * Consistency in build commands for free from automake. Right now we have the compiling and linking commands repeated throughout the tree and they're typically out of sync. I've tried to keep them in sync before and it was a lot of effort. With automake all you really need to do is tell it the CFLAGS and LIBS to use and it'll take care of the rest. * Parallel make jobs just work. I've fixed so many of these race condition bugs, but they'd all just go away using automake. It has all the goop built in that people usually never think about. * Well defined distribution for tarballs. The top-level Makefile does the job, but automake can make this a lot easier and more robust. It would also be simple to handle the generated files while also requiring they be included in the tarball. * Fast source dependencies without external tools. The makedepend route works, but automake handles this in a faster, more robust and safer manner. We get a lot of people posting to the mailing list about build errors were the solution is "make realclean". This would solve a lot of those issues. * Mindshare from xorg autotools. Many of the people here have and do work with the autotools via xorg, so it's not like this is a completely foreign beast. * Moves the burden of build tool knowledge onto someone else. I don't think anyone here wants to become an expert on compilers, linkers and ABI for multiple platforms. It become a lot easier when you toss things off to libtool where people are actually spending their time caring about them. * Extensive documentation available, unlike the current system which is pretty much ad hoc. http://www.gnu.org/software/autoconf/manual/autoconf.html http://www.gnu.org/software/automake/manual/automake.html http://www.gnu.org/software/libtool/manual/libtool.html http://sourceware.org/autobook/autobook/autobook.html Cons: * The abstracted nature of automake causes build debugging to be difficult. This requires you to train your brain not to look at the generated Makefile, but still it can be difficult. Fortunately, many of the build bugs we see today in Mesa would go away with automake. * Using libtool means that you can't quickly hack around a fix for some platform. Fortunately, libtool is a lot more stable these days on common platforms. * The maintainer (you) doesn't like it. Not much I can suggest here besides that it gets a lot easier the more you deal with it. And I'd be happy to help you out of any jams. For xorg, Peter Hutterer has asked me to solve a bunch of these problems, and I can't remember the last time we couldn't get something fixed. * Loss of the simple "make $target" usage. I understand you guys use these targets to quickly pop out a build. As a compromise, we could turn the configs into wrapper scripts that generated the autotools files and ran configure with appropriate arguments. For example, "./configs/linux-debug && make". Or, since configure handles the platform parts, ./configs/debug or ./configs/osmesa. That's all I can think of. I'm sure we can continue to make the current system work, but I think integrating these tools would be a big improvement. Thanks for considering it. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Current tinderbox regression (egl, parallel make)
On Mon, Apr 26, 2010 at 2:16 PM, Chris Ball wrote: > Hi, > > http://tinderbox.x.org/builds/2010-04-26-0020/logs/libGL/#build > > gmake[3]: *** No rule to make target `depend', needed by `default'. Stop. > gmake[2]: *** [../../../progs/egl/eglut/libeglut-screen.a] Error 2 > gmake[2]: *** Waiting for unfinished jobs > [...] > ar: creating libeglut-x11.a > ar: creating libeglut-screen.a > make[1]: *** [subdirs] Error 1 > make: *** [default] Error 1 > > Seems to have broken in the last twelve hours or so, building with -j4. > It's repeatable across build attempts. progs/egl/opengl/Makefile is really nasty and makes this tough to debug. I can't tell exactly what causes the error, but the build is trying to jump from egl/opengl to egl/eglut to build the two convenience libraries. Why it sees the depend target but not the rule, I don't know. Does it build without parallel jobs? It would be much better if egl/eglut was just built first before going to build the demos. Adding Chia-I since I can't really tell what's supposed to be happening. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [RFC] Branch maintenance
On Fri, Apr 23, 2010 at 6:06 AM, Jakob Bornecrantz wrote: > On 2010-04-23 13.03, Keith Whitwell wrote: >> >> On Fri, 2010-04-23 at 04:12 -0700, Jakob Bornecrantz wrote: >> >>> >>> Hi all >>> >>> So mesa has a fair bit of branches just laying around not doing >>> anything. I wrote a quick script that prints the branch name and the >>> number of commits that this branch has which are not on the master >>> branch. I have attached a full list but here is a random short list: >>> >>> gallium-s3tc: 0 >>> gallium-sampler-view: 0 >>> gallium-screen-context: 3 >>> gallium-softpipe-winsys: 1 >>> gallium-st-api: 0 >>> gallium-st-api-dri: 0 >>> gallium-strict-aliasing: 0 >>> gallium-sw-api: 6 >>> gallium-sw-api-2: 0 >>> gallium-targets: 0 >>> gallium-tex-surfaces: 0 >>> gallium-texture-transfer: 0 >>> gallium-tgsi-semantic-cleanup: 0 >>> gallium-util-format-is-supported: 1 >>> gallium-vertex-linear: 0 >>> gallium-vertexelementcso: 0 >>> gallium-wgl-rework: 0 >>> gallium-winsys-handle: 7 >>> gallium-winsys-handle-rebased: 0 >>> gallium-winsys-private: 1 >>> >>> Quite a fair bit branch that has no special commits, is it okay to >>> remove those? I know this a bit of throwing a stone in a glass house >>> considering I'm responsible for a fair bit, 4 of those just from the >>> list in the mail. >>> >> >> I've been removing dead branches for quite a while now as I find them& >> have motivation. Certainly I think we can remove all the "zero"s... >> > > Right, hmm it looks like git doesn't remove local remote branches > automatically, so my list is quite outdated. Here is a updated list, have > removed one zero branch that was mine. And I'm probably am going to remove > gallium-winsys-handle (which got rebased). FYI, "git remote prune", "git pull --prune" and "git fetch --prune" can handle this for you. -- Dan ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
