Re: [PULL 1.9] xfree86 fixes
Done. Thanks. 5b64f85..4d2542a server-1.9-branch -> server-1.9-branch This will likely be what gets tagged as 1.9.1rc1 on Friday. If anyone has anything else before then, please drop me a line. On Sep 29, 2010, at 11:11, Adam Jackson wrote: > Jeremy, please pull this from this branch. Fixes a warning and a minor > memory leak, and adds 18bpp and nds32 arch support. > > --- > > The following changes since commit 6a0b4051972a4fa6f1a3b22ec1ae54bd1849bc9f: > > XQuartz: RandR: Refactor legacy mode-switching to be better integrated with > RandR (2010-09-28 18:54:40 -0700) > > are available in the git repository at: > ssh://people.freedesktop.org/~ajax/xserver.git server-1.9-xfree86 > > Adam Jackson (1): > xfree86: Add 18bpp support > > Jesse Adkins (1): > xfree86: Fix leaks in OpenConfigFile and OpenConfigDir > > Macpaul Lin (3): > xfree86: nds32: add nds32 definition for vgaHW support. > xfree86: nds32: add nds32 support for compiler specific codes > xfree86: nds32: add nds32 support for compiler related mmio codes > > Peter Hutterer (1): > xfree86: fix compiler warning about implicied decl of DuplicateModule. > > hw/xfree86/common/compiler.h | 416 +++- > hw/xfree86/common/xf86Helper.c |3 + > hw/xfree86/common/xf86Xinput.c |1 + > hw/xfree86/parser/scan.c |2 + > hw/xfree86/vgahw/vgaHW.h |2 +- > 5 files changed, 420 insertions(+), 4 deletions(-) > > - ajax ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-geode: Changes to 'master'
On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote: > Agree. > But that will revert totally 5/29/2010 patch. > It will be exactly equivalent to the current code. So no. Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: xf86-video-geode: Changes to 'master'
So we can keep the current git code with no change. > -Original Message- > From: Julien Cristau [mailto:jcris...@debian.org] > Sent: 2010?9?30? 15:47 > To: Huang, FrankR > Cc: Otavio Salvador; Geode Mailing List; q-f...@iki.fi; xorg- > de...@lists.x.org > Subject: Re: xf86-video-geode: Changes to 'master' > > On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote: > > > Agree. > > But that will revert totally 5/29/2010 patch. > > > It will be exactly equivalent to the current code. So no. > > Cheers, > Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: xf86-video-geode: Changes to 'master'
Agree.
But that will revert totally 5/29/2010 patch.
Thanks,
Frank
> -Original Message-
> From: Julien Cristau [mailto:jcris...@debian.org]
> Sent: 2010?9?30? 14:28
> To: Huang, FrankR
> Cc: Geode Mailing List; q-f...@iki.fi; xorg-devel@lists.x.org
> Subject: Re: xf86-video-geode: Changes to 'master'
>
> On Thu, Sep 30, 2010 at 13:56:27 +0800, Huang, FrankR wrote:
>
> > I definitely know MODE_OK will be returned in this function now for
> > every condition. But you should know my patch is based on the patch
> > Otavio committed on 5/29/2010. If there is some condition we need give
> > MODE_XXX, we can add code. But the last return value of this function
> > must be MODE_OK. That is my point.
>
> Then write it as
>
> lx_output_mode_valid()
> {
> return MODE_OK;
> }
>
> which will be equivalent to the current code, but not quite as
> convoluted.
>
> Cheers,
> Julien
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[xserver patch] remove dolt
With libtool 2.2.10 the difference in build time is so small
(< 5% with -j8 builds) that it isn't worth having this hack.
Signed-off-by: Adrian Bunk
---
Makefile.am |2 -
configure.ac |1 -
m4/dolt.m4 | 181 --
3 files changed, 0 insertions(+), 184 deletions(-)
delete mode 100644 m4/dolt.m4
diff --git a/Makefile.am b/Makefile.am
index 8b7a2c8..62c8d95 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -56,8 +56,6 @@ DISTCHECK_CONFIGURE_FLAGS=\
--with-xkb-bin-directory=$(XKB_BIN_DIRECTORY) \
--with-xkb-output='$${datadir}/X11/xkb/compiled'
-DISTCLEANFILES = doltcompile doltlibtool
-
.PHONY: ChangeLog INSTALL
INSTALL:
diff --git a/configure.ac b/configure.ac
index 825eb69..479f54f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -71,7 +71,6 @@ AC_PROG_LN_S
AC_LIBTOOL_WIN32_DLL
AC_DISABLE_STATIC
AC_PROG_LIBTOOL
-DOLT
AC_PROG_MAKE_SET
PKG_PROG_PKG_CONFIG
AC_PROG_LEX
diff --git a/m4/dolt.m4 b/m4/dolt.m4
deleted file mode 100644
index 7c62b6c..000
--- a/m4/dolt.m4
+++ /dev/null
@@ -1,181 +0,0 @@
-dnl dolt, a replacement for libtool
-dnl Copyright © 2007-2008 Josh Triplett
-dnl Copying and distribution of this file, with or without modification,
-dnl are permitted in any medium without royalty provided the copyright
-dnl notice and this notice are preserved.
-dnl
-dnl To use dolt, invoke the DOLT macro immediately after the libtool macros.
-dnl Optionally, copy this file into acinclude.m4, to avoid the need to have it
-dnl installed when running autoconf on your project.
-
-AC_DEFUN([DOLT], [
-AC_REQUIRE([AC_CANONICAL_HOST])
-# dolt, a replacement for libtool
-# Josh Triplett
-AC_PATH_PROG(DOLT_BASH, bash)
-AC_MSG_CHECKING([if dolt supports this host])
-dolt_supported=yes
-if test x$DOLT_BASH = x; then
-dolt_supported=no
-fi
-if test x$GCC != xyes; then
-dolt_supported=no
-fi
-case $host in
-i?86-*-linux*|x86_64-*-linux*|powerpc-*-linux* \
-|amd64-*-freebsd*|i?86-*-freebsd*|ia64-*-freebsd*)
-pic_options='-fPIC'
-;;
-i?86-pc-cygwin*)
-pic_options='-DDLL_EXPORT'
-;;
-i?86-apple-darwin*)
-pic_options='-fno-common'
-;;
-*)
-dolt_supported=no
-;;
-esac
-if test x$dolt_supported = xno ; then
-AC_MSG_RESULT([no, falling back to libtool])
-LTCOMPILE='$(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
--mode=compile $(COMPILE)'
-LTCXXCOMPILE='$(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
--mode=compile $(CXXCOMPILE)'
-else
-AC_MSG_RESULT([yes, replacing libtool])
-
-dnl Start writing out doltcompile.
-cat <<__DOLTCOMPILE__EOF__ >doltcompile
-#!$DOLT_BASH
-__DOLTCOMPILE__EOF__
-cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
-args=("$[]@")
-for ((arg=0; arg<${#args@<:@@@:>@}; arg++)) ; do
-if test x"${args@<:@$arg@:>@}" = x-o ; then
-objarg=$((arg+1))
-break
-fi
-done
-if test x$objarg = x ; then
-echo 'Error: no -o on compiler command line' 1>&2
-exit 1
-fi
-lo="${args@<:@$objarg@:>@}"
-obj="${lo%.lo}"
-if test x"$lo" = x"$obj" ; then
-echo "Error: libtool object file name \"$lo\" does not end in .lo" 1>&2
-exit 1
-fi
-objbase="${obj##*/}"
-__DOLTCOMPILE__EOF__
-
-dnl Write out shared compilation code.
-if test x$enable_shared = xyes; then
-cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
-libobjdir="${obj%$objbase}.libs"
-if test ! -d "$libobjdir" ; then
-mkdir_out="$(mkdir "$libobjdir" 2>&1)"
-mkdir_ret=$?
-if test "$mkdir_ret" -ne 0 && test ! -d "$libobjdir" ; then
- echo "$mkdir_out" 1>&2
-exit $mkdir_ret
-fi
-fi
-pic_object="$libobjdir/$objbase.o"
-args@<:@$objarg@:>@="$pic_object"
-__DOLTCOMPILE__EOF__
-cat <<__DOLTCOMPILE__EOF__ >>doltcompile
-"\${args@<:@@@:>@}" $pic_options -DPIC || exit \$?
-__DOLTCOMPILE__EOF__
-fi
-
-dnl Write out static compilation code.
-dnl Avoid duplicate compiler output if also building shared objects.
-if test x$enable_static = xyes; then
-cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
-non_pic_object="$obj.o"
-args@<:@$objarg@:>@="$non_pic_object"
-__DOLTCOMPILE__EOF__
-if test x$enable_shared = xyes; then
-cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
-"${args@<:@@@:>@}" >/dev/null 2>&1 || exit $?
-__DOLTCOMPILE__EOF__
-else
-cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
-"${args@<:@@@:>@}" || exit $?
-__DOLTCOMPILE__EOF__
-fi
-fi
-
-dnl Write out the code to write the .lo file.
-dnl The second line of the .lo file must match "^# Generated by .*libtool"
-cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
-{
-echo "# $lo - a libtool object file"
-echo "# Generated by doltcompile, not libtool"
-__DOLTCOMPILE__EOF__
-
-if test x$enable_shared = xyes; then
-cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
-echo "pic_object='.libs/${objbase}.o'"
-__DOLTCOMPILE__EOF__
-else
-cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
-echo pic_object=none
-__DOLTCOMPILE__EOF__
-fi
Re: [xserver patch] remove dolt
On Thu, Sep 30, 2010 at 01:18:20PM +0300, Adrian Bunk wrote: > With libtool 2.2.10 the difference in build time is so small > (< 5% with -j8 builds) that it isn't worth having this hack. > > Signed-off-by: Adrian Bunk Reviewed-by: Daniel Stone signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-geode: Changes to 'master'
On Thu, Sep 30, 2010 at 4:46 AM, Julien Cristau wrote: > On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote: > >> Agree. >> But that will revert totally 5/29/2010 patch. >> > It will be exactly equivalent to the current code. So no. It is not equivalent. -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [xserver patch] remove dolt
On Thu, Sep 30, 2010 at 3:18 AM, Adrian Bunk wrote: > With libtool 2.2.10 the difference in build time is so small > (< 5% with -j8 builds) that it isn't worth having this hack. > > Signed-off-by: Adrian Bunk Reviewed-by: Dan Nicholson ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote: > As we learned on XDS, this sort of, what others would call, basic > diligence, like testing some graphics drivers first, would only be > reserved for drivers which would've been merged back into the server > tree. You're putting words in people's mouths there. You can stop doing that any time now, it's getting a bit tiring. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Thu, Sep 30, 2010 at 09:52:30AM -0400, Adam Jackson wrote: > On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote: > > > As we learned on XDS, this sort of, what others would call, basic > > diligence, like testing some graphics drivers first, would only be > > reserved for drivers which would've been merged back into the server > > tree. > > You're putting words in people's mouths there. You can stop doing that > any time now, it's getting a bit tiring. > > - ajax I am not sure whether Michael Larabel already made the audio or video recordings of the "xserver 1.10 planning" session available. The above is the interpretation that i made of some of the statements made during that "discussion". Maybe this is not exactly what you or Keith meant, but it is how it was understood. Feel free to elaborate on what you really meant. Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: xf86-video-geode: Changes to 'master'
On Thu, 2010-09-30 at 15:49 +0800, Huang, FrankR wrote: > So we can keep the current git code with no change. You can, but the code is still _wrong_. Wrong wrong wrong. Your hardware has real constraints; you have finite memory bandwidth, and finite DAC speed, and finite CRTC addressibility. If I try this modeline on your hardware: atropine:~% gtf 1920 1440 120 # 1920x1440 @ 120.00 Hz (GTF) hsync: 185.16 kHz; pclk: 497.71 MHz Modeline "1920x1440_120.00" 497.71 1920 2088 2304 2688 1440 1441 1444 1543 -HSync +Vsync it will not work. The code as you've now changed it will happily accept this mode. And your commit message is wrong too. The other drivers you mention check for failure conditions before returning MODE_OK. You're checking for _success_ conditions and then returning MODE_OK all the time. Textually these look very similar; semantically they're completely different. Think. Please. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: xf86-video-geode: Changes to 'master'
On Thu, Sep 30, 2010 at 08:49:55AM -0300, Otavio Salvador wrote: > On Thu, Sep 30, 2010 at 4:46 AM, Julien Cristau wrote: > > On Thu, Sep 30, 2010 at 15:38:07 +0800, Huang, FrankR wrote: > > > >> Agree. > >> But that will revert totally 5/29/2010 patch. > >> > > It will be exactly equivalent to the current code. So no. > > It is not equivalent. The code will now always return MODE_OK and this function shouldn't be modifying any of its parameters, so how is it not equivalent? -- Matthew Garrett | mj...@srcf.ucam.org ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: problem with multithreaded application and Xlib
Hi all, I don't really want to bother you guys, I know that you have all very important developments ongoing. Actually I don't ask you to help me about this particular problem that I've found with the snapshot release of the Xserver/Xlib. What I would like to understand is if the technique that I'm using with the two threads is actually correct or not. Can I safely assume that my program does not works just because of a bug in the snapshot release ? There is a more correct way to do what I'm doing ? I will be grateful if I could have at least some hints. Thank you very much in advance. My previous mail follow below. Francesco 2010/9/28 Francesco Abbate : > Hi all, > > I've recently made the switch to the snapshot xorg server and the > related X libraries and I've discovered that my application stopped to > works correctly! > > Here the problem in short. I'm developing a multi-threaded application > where the main thread run the X Window event loop. There is also a > secondary thread that sometimes need to redraw the window or, more > generally, perform operation on the X Display. In order to avoid > problems I've arranged some locks so that the secondary thread perform > its operations on the display only when the main thread is blocking in > the XNextEvent operation. At this point is important to add that, yes, > I'm using the XInitThread functions at the very beginning of the main > loop. > > What happens is that the secondary thread blocks during the XSync > operation until the main thread receive some events. > > I'm wondering if the assumption that I'm doing in my code is wrong or > if it is a bug of the X server or may be the X library. It seems to me > that it is like if Xlib does not honor the XInitThreads call because > it does not allow an ordinary XSync to terminate if there is a pending > XNextEevent call at the same time (by another thread). > > I hope someone can help me to clarify the problem. > > Best regards, > Francesco > -- Francesco ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: problem with multithreaded application and Xlib
On Thu, Sep 30, 2010 at 17:44:23 +0200, Francesco Abbate wrote: > I will be grateful if I could have at least some hints. Thank you very > much in advance. Did you try the libxcb patch suggested by Peter? Cheers, Julien ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: problem with multithreaded application and Xlib
On Thu, 2010-09-30 at 17:44 +0200, Francesco Abbate wrote: > ...Xlib. What I would like to understand is if the > technique that I'm using with the two threads is actually correct or > not. Xlib is not designed to be thread-safe. You should make Xlib calls from only one thread, or ensure that use of it is transferred coherently and wholesale from one thread to another. -- -- From: Jonathan Morton jonathan.mor...@movial.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [xserver patch] remove dolt
Good riddance.
Reviewed-by: Jeremy Huddleston
On Sep 30, 2010, at 03:18, Adrian Bunk wrote:
> With libtool 2.2.10 the difference in build time is so small
> (< 5% with -j8 builds) that it isn't worth having this hack.
>
> Signed-off-by: Adrian Bunk
>
> ---
> Makefile.am |2 -
> configure.ac |1 -
> m4/dolt.m4 | 181 --
> 3 files changed, 0 insertions(+), 184 deletions(-)
> delete mode 100644 m4/dolt.m4
>
> diff --git a/Makefile.am b/Makefile.am
> index 8b7a2c8..62c8d95 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -56,8 +56,6 @@ DISTCHECK_CONFIGURE_FLAGS=\
> --with-xkb-bin-directory=$(XKB_BIN_DIRECTORY) \
> --with-xkb-output='$${datadir}/X11/xkb/compiled'
>
> -DISTCLEANFILES = doltcompile doltlibtool
> -
> .PHONY: ChangeLog INSTALL
>
> INSTALL:
> diff --git a/configure.ac b/configure.ac
> index 825eb69..479f54f 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -71,7 +71,6 @@ AC_PROG_LN_S
> AC_LIBTOOL_WIN32_DLL
> AC_DISABLE_STATIC
> AC_PROG_LIBTOOL
> -DOLT
> AC_PROG_MAKE_SET
> PKG_PROG_PKG_CONFIG
> AC_PROG_LEX
> diff --git a/m4/dolt.m4 b/m4/dolt.m4
> deleted file mode 100644
> index 7c62b6c..000
> --- a/m4/dolt.m4
> +++ /dev/null
> @@ -1,181 +0,0 @@
> -dnl dolt, a replacement for libtool
> -dnl Copyright © 2007-2008 Josh Triplett
> -dnl Copying and distribution of this file, with or without modification,
> -dnl are permitted in any medium without royalty provided the copyright
> -dnl notice and this notice are preserved.
> -dnl
> -dnl To use dolt, invoke the DOLT macro immediately after the libtool macros.
> -dnl Optionally, copy this file into acinclude.m4, to avoid the need to have
> it
> -dnl installed when running autoconf on your project.
> -
> -AC_DEFUN([DOLT], [
> -AC_REQUIRE([AC_CANONICAL_HOST])
> -# dolt, a replacement for libtool
> -# Josh Triplett
> -AC_PATH_PROG(DOLT_BASH, bash)
> -AC_MSG_CHECKING([if dolt supports this host])
> -dolt_supported=yes
> -if test x$DOLT_BASH = x; then
> -dolt_supported=no
> -fi
> -if test x$GCC != xyes; then
> -dolt_supported=no
> -fi
> -case $host in
> -i?86-*-linux*|x86_64-*-linux*|powerpc-*-linux* \
> -|amd64-*-freebsd*|i?86-*-freebsd*|ia64-*-freebsd*)
> -pic_options='-fPIC'
> -;;
> -i?86-pc-cygwin*)
> -pic_options='-DDLL_EXPORT'
> -;;
> -i?86-apple-darwin*)
> -pic_options='-fno-common'
> -;;
> -*)
> -dolt_supported=no
> -;;
> -esac
> -if test x$dolt_supported = xno ; then
> -AC_MSG_RESULT([no, falling back to libtool])
> -LTCOMPILE='$(LIBTOOL) --tag=CC $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
> --mode=compile $(COMPILE)'
> -LTCXXCOMPILE='$(LIBTOOL) --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)
> --mode=compile $(CXXCOMPILE)'
> -else
> -AC_MSG_RESULT([yes, replacing libtool])
> -
> -dnl Start writing out doltcompile.
> -cat <<__DOLTCOMPILE__EOF__ >doltcompile
> -#!$DOLT_BASH
> -__DOLTCOMPILE__EOF__
> -cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> -args=("$[]@")
> -for ((arg=0; arg<${#args@<:@@@:>@}; arg++)) ; do
> -if test x"${args@<:@$arg@:>@}" = x-o ; then
> -objarg=$((arg+1))
> -break
> -fi
> -done
> -if test x$objarg = x ; then
> -echo 'Error: no -o on compiler command line' 1>&2
> -exit 1
> -fi
> -lo="${args@<:@$objarg@:>@}"
> -obj="${lo%.lo}"
> -if test x"$lo" = x"$obj" ; then
> -echo "Error: libtool object file name \"$lo\" does not end in .lo" 1>&2
> -exit 1
> -fi
> -objbase="${obj##*/}"
> -__DOLTCOMPILE__EOF__
> -
> -dnl Write out shared compilation code.
> -if test x$enable_shared = xyes; then
> -cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> -libobjdir="${obj%$objbase}.libs"
> -if test ! -d "$libobjdir" ; then
> -mkdir_out="$(mkdir "$libobjdir" 2>&1)"
> -mkdir_ret=$?
> -if test "$mkdir_ret" -ne 0 && test ! -d "$libobjdir" ; then
> - echo "$mkdir_out" 1>&2
> -exit $mkdir_ret
> -fi
> -fi
> -pic_object="$libobjdir/$objbase.o"
> -args@<:@$objarg@:>@="$pic_object"
> -__DOLTCOMPILE__EOF__
> -cat <<__DOLTCOMPILE__EOF__ >>doltcompile
> -"\${args@<:@@@:>@}" $pic_options -DPIC || exit \$?
> -__DOLTCOMPILE__EOF__
> -fi
> -
> -dnl Write out static compilation code.
> -dnl Avoid duplicate compiler output if also building shared objects.
> -if test x$enable_static = xyes; then
> -cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> -non_pic_object="$obj.o"
> -args@<:@$objarg@:>@="$non_pic_object"
> -__DOLTCOMPILE__EOF__
> -if test x$enable_shared = xyes; then
> -cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> -"${args@<:@@@:>@}" >/dev/null 2>&1 || exit $?
> -__DOLTCOMPILE__EOF__
> -else
> -cat <<'__DOLTCOMPILE__EOF__' >>doltcompile
> -"${args@<:@@@:>@}" || exit $?
> -__DOLTCOMPILE__EOF__
> -fi
> -fi
> -
> -dnl Write out the code to write the .lo file.
> -dnl The second line of the .lo file must match "^# Generated by .*libtool"
> -cat <<'__DOLTCOMPILE__EOF__' >>doltc
Re: problem with multithreaded application and Xlib
On 09/30/2010 06:44 PM, Francesco Abbate wrote: What happens is that the secondary thread blocks during the XSync operation until the main thread receive some events. Hi, XNextEvent may call _XReadEvents and XSync calls _XReply. If XNextEvent is called before XSync from a different thread and there are no events, this may happen. It's a bug in Xlib implementation. Search for "FIXME" in http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xcb_io.c. I don't know if you are facing this problem but based on your description that may be the case. Best regards, Francesco -- Rami ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Thu, 2010-09-30 at 16:11 +0200, Luc Verhaegen wrote: > On Thu, Sep 30, 2010 at 09:52:30AM -0400, Adam Jackson wrote: > > On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote: > > > As we learned on XDS, this sort of, what others would call, basic > > > diligence, like testing some graphics drivers first, would only be > > > reserved for drivers which would've been merged back into the server > > > tree. > > > > You're putting words in people's mouths there. You can stop doing that > > any time now, it's getting a bit tiring. > > I am not sure whether Michael Larabel already made the audio or video > recordings of the "xserver 1.10 planning" session available. The above > is the interpretation that i made of some of the statements made during > that "discussion". I believe you're conflating "changes that break the build of merged drivers will not be pushed" with "drivers merged in the server are the only ones that matter" which, okay, that's a pretty standard comprehension failure for you I suppose. - ajax signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: problem with multithreaded application and Xlib
2010/9/30 Julien Cristau : > On Thu, Sep 30, 2010 at 17:44:23 +0200, Francesco Abbate wrote: > >> I will be grateful if I could have at least some hints. Thank you very >> much in advance. > > Did you try the libxcb patch suggested by Peter? Well, I've tried the patch of Peter and it did not change absolutely nothing. I've recompiled the libxcb and replaced the shared library in my system and I've got virtually no change at all. Francesco ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Thu, Sep 30, 2010 at 01:51:27PM -0400, Adam Jackson wrote: > > > On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote: > > > > As we learned on XDS, this sort of, what others would call, basic > > > > diligence, like testing some graphics drivers first, would only be > > > > reserved for drivers which would've been merged back into the server > > > > tree. > > I believe you're conflating > > "changes that break the build of merged drivers will not be pushed" > > with > > "drivers merged in the server are the only ones that matter" > > which, okay, that's a pretty standard comprehension failure for you I > suppose. > > - ajax Please re-read the above and your subsequent statements. Your first statement does indeed say: we are free to push changes which break drivers, without taking responsibility for unbreaking those drivers. Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Thu, Sep 30, 2010 at 08:49:39PM +0200, Luc Verhaegen wrote: > On Thu, Sep 30, 2010 at 01:51:27PM -0400, Adam Jackson wrote: > > > > > On Wed, 2010-09-29 at 22:48 +0200, Luc Verhaegen wrote: > > > > > > As we learned on XDS, this sort of, what others would call, basic > > > > > diligence, like testing some graphics drivers first, would only be > > > > > reserved for drivers which would've been merged back into the server > > > > > tree. > > > > I believe you're conflating > > > > "changes that break the build of merged drivers will not be pushed" > > > > with > > > > "drivers merged in the server are the only ones that matter" > > > > which, okay, that's a pretty standard comprehension failure for you I > > suppose. > > > > - ajax > > Please re-read the above and your subsequent statements. > > Your first statement does indeed say: we are free to push changes which > break drivers, without taking responsibility for unbreaking those > drivers. > > Luc Verhaegen. One empty bladder later; You're right, i am mixing things here... "changes that break the build of merged drivers will not be pushed"... to the server by the release manager of the server. That's just stating: the server release manager cannot be bothered to look any further. How about if this sort of strategy was actively applied: changes from which the release manager assumes that they will break driver will be withheld until this fear is proven wrong or until the issues are solved/patches are provided to fix this. Maybe combined with a posterior tactic of making the author of the breaking patch responsible for breakage, which might finally instill proactive and forward thinking in some developers. Luc Verhaegen. ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: problem with multithreaded application and Xlib
2010/9/30 Rami Ylimäki : > XNextEvent may call _XReadEvents and XSync calls _XReply. If XNextEvent is > called before XSync from a different thread and there are no events, this > may happen. It's a bug in Xlib implementation. Search for "FIXME" in > http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/xcb_io.c. I don't know > if you are facing this problem but based on your description that may be the > case. Hi Rami, this sounds interesting. Actually I strongly suspect libxcb for this problem. As you pointed out in xcb_io.c there is a FIXME comment so the developers *are* aware of the problem. I'm wondering if I should post the problem in the xcb mailing list. Or may be I've just to switch back to the stable version of X Window and wait for this bug to be fixed for the next release. The problem is that I needs to have at least OpenGL 2 to use shaders and the binary ATI driver does not works (sic!). The development with the Gallium architecture is very interesting and exciting but for the moment it is just not ready :-) Thank you very much for the help! Francesco ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Build error: pixmapPrivate
On Thu, Sep 30, 2010 at 08:59:46PM +0200, Luc Verhaegen wrote: >... > How about if this sort of strategy was actively applied: changes from > which the release manager assumes that they will break driver will be > withheld until this fear is proven wrong or until the issues are > solved/patches are provided to fix this. >... That wouldn't have made a difference: The commit that broke it was submitted three times to this list, with 2 weeks between the first submission and the patch being applied. As far as I can see, noone (including me and you) raised any objections before it was applied. > Luc Verhaegen. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: don't create core motion events for non-x/y valuators.
On Tue, Aug 17, 2010 at 1:08 AM, Bartosz Brachaczek
wrote:
> 2010/8/17 Peter Hutterer :
>> Devices that send motion events with valuators other than x/y get core
>> motion events with unchanged x/y coordinates. This confuses some
>> applications.
>>
>> If the DeviceEvent does not have the x/y valuators set, return BadMatch on
>> core conversion, thus skipping the event altogether.
>>
>> Reported-by: Bartosz Brachaczek
>> Signed-off-by: Peter Hutterer
>> ---
>> dix/eventconvert.c | 9 +
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/dix/eventconvert.c b/dix/eventconvert.c
>> index 4e3de0b..0f747c1 100644
>> --- a/dix/eventconvert.c
>> +++ b/dix/eventconvert.c
>> @@ -102,6 +102,15 @@ EventToCore(InternalEvent *event, xEvent *core)
>> switch(event->any.type)
>> {
>> case ET_Motion:
>> + {
>> + DeviceEvent *e = &event->device_event;
>> + /* Don't create core motion event if neither x nor y are
>> + * present */
>> + if (!BitIsOn(e->valuators.mask, 0) &&
>> + !BitIsOn(e->valuators.mask, 1))
>> + return BadMatch;
>> + }
>> + /* fallthrough */
>> case ET_ButtonPress:
>> case ET_ButtonRelease:
>> case ET_KeyPress:
>> --
>> 1.7.2.1
>>
>>
>
> Tested-by: Bartosz Brachaczek
>
> This fixes the issue for me. Thanks a lot!
> ___
> xorg-devel@lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel
This seems to have broken the tests on server-1.9-branch?
/xkb/set-get-rules: OK
/xkb/get-rules: OK
/xkb/set-rules: OK
PASS: xkb
/dix/input/attributes: OK
/dix/input/init-valuators: OK
/dix/input/event-core-conversion: [dix] EventToCore: Not implemented yet
[dix] EventToCore: Not implemented yet
[dix] EventToCore: Not implemented yet
**
ERROR:../../test/input.c:192:dix_event_to_core: assertion failed: (rc
== Success)
/bin/bash: line 5: 20500 Aborted ${dir}$tst
FAIL: input
/dix/xtest/init: OK
/dix/xtest/properties: OK
PASS: xtest
1 of 3 tests failed
Please report to https://bugs.freedesktop.org/enter_bug.cgi?product=xorg
It passes and builds fine after reverting this commit. Also -
https://bugs.freedesktop.org/show_bug.cgi?id=30267
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 00/10] build.sh script cleanup
From: Trevor Woerner Hi everyone, I've created a bunch of cleanup patches that I'm hoping will be considered for the modular build script. I believe they make working with the script, and using it, nicer. Trevor Woerner (10): Provide visual separation between modules. Provide earlier module/component title. Centralize build mode logic. Document functions in build.sh. Add preconditions. Indentation cleanup. Whitespace cleanup. Clean up "clone" logic. Rely on "git clone" return value. Provide nicer failed component listing. build.sh | 296 +- 1 files changed, 216 insertions(+), 80 deletions(-) -- 1.7.3.1.45.g9855b ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 01/10] Provide visual separation between modules.
From: Trevor Woerner
When reviewing a build log or watching a build, it is easier to see which
module/component is being processed at arbitrary points if a clear, visual
separation exists between the processing of each module/component.
Signed-off-by: Trevor Woerner
---
build.sh | 18 +-
1 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/build.sh b/build.sh
index 816c81d..f73142c 100755
--- a/build.sh
+++ b/build.sh
@@ -74,6 +74,22 @@ failed() {
fi
}
+# print a pretty title to separate the processing of each module
+# arguments:
+# $1 - string to format into title
+# returns:
+# (irrelevant)
+module_title() {
+# preconds
+if [ X"$1" = X ]; then
+ return
+fi
+
+echo ""
+echo
"=="
+echo "== Processing module/component: \"$1/$2\""
+}
+
checkfortars() {
M=$1
C=$2
@@ -218,7 +234,7 @@ build() {
return
fi
-echo "Processing module/component $1/$2"
+module_title $1 $2
if [ X"$BUILT_MODULES_FILE" != X ]; then
echo "$1/$2" >> $BUILT_MODULES_FILE
--
1.7.3.1.45.g9855b
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 02/10] Provide earlier module/component title.
From: Trevor Woerner
I would like to see the module/component title appear
before the configuration/clone step.
Signed-off-by: Trevor Woerner
---
build.sh |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/build.sh b/build.sh
index f73142c..3a57561 100755
--- a/build.sh
+++ b/build.sh
@@ -206,6 +206,8 @@ build() {
fi
fi
+module_title $1 $2
+
SRCDIR=""
CONFCMD=""
if [ -f $1/$2/autogen.sh ]; then
@@ -234,8 +236,6 @@ build() {
return
fi
-module_title $1 $2
-
if [ X"$BUILT_MODULES_FILE" != X ]; then
echo "$1/$2" >> $BUILT_MODULES_FILE
fi
--
1.7.3.1.45.g9855b
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 03/10] Centralize build mode logic.
From: Trevor Woerner
Place into one location the logic to decide what to do with regards to
the following build modes: LISTONLY, RESUME, NOQUIT, and BUILD_ONE.
Signed-off-by: Trevor Woerner
---
build.sh | 163 --
1 files changed, 116 insertions(+), 47 deletions(-)
diff --git a/build.sh b/build.sh
index 3a57561..2bfcebb 100755
--- a/build.sh
+++ b/build.sh
@@ -66,12 +66,8 @@ nonexistent_components=""
clonefailed_components=""
failed() {
-if [ X"${NOQUIT}" != X ]; then
- echo "* $1 failed on $2/$3"
- failed_components="$failed_components $2/$3"
-else
- exit 1
-fi
+echo "* $1 failed on $2/$3"
+failed_components="$failed_components $2/$3"
}
# print a pretty title to separate the processing of each module
@@ -147,12 +143,18 @@ checkfortars() {
if [ X"$jj" = X"gz" ]; then
TAROPTS=xzf
fi
-tar $TAROPTS $TARFILE -C $ii || failed tar $1 $2
+tar $TAROPTS $TARFILE -C $ii
+ if [ $? -ne 0 ]; then
+ failed tar $1 $2
+ return 1
+ fi
fi
-return
+return 0
fi
done
done
+
+return 0
}
clone() {
@@ -190,21 +192,8 @@ clone() {
return 0
}
-build() {
-if [ X"$LISTONLY" != X ]; then
- echo "$1/$2"
- return 0
-fi
-
-if [ X"$RESUME" != X ]; then
- if [ X"$RESUME" = X"$1/$2" ]; then
- unset RESUME
- # Resume build at this module
- else
- echo "Skipping $1 module component $2..."
- return 0
- fi
-fi
+process() {
+local rtn
module_title $1 $2
@@ -218,10 +207,7 @@ build() {
if [ $? -ne 0 ]; then
echo "Failed to clone $1 module component $2. Ignoring."
clonefailed_components="$clonefailed_components $1/$2"
-if [ X"$BUILD_ONE" != X ]; then
-exit 1
-fi
-return
+return 1
fi
SRCDIR="$1/$2"
CONFCMD="autogen.sh"
@@ -233,7 +219,7 @@ build() {
if [ X"$SRCDIR" = X ]; then
echo "$1 module component $2 does not exist, skipping."
nonexistent_components="$nonexistent_components $1/$2"
-return
+return 0
fi
if [ X"$BUILT_MODULES_FILE" != X ]; then
@@ -241,38 +227,56 @@ build() {
fi
old_pwd=`pwd`
-cd $SRCDIR || failed cd1 $1 $2
+cd $SRCDIR
+if [ $? -ne 0 ]; then
+ failed cd1 $1 $2
+ return 1
+fi
if [ X"$GITCMD" != X ]; then
$GITCMD
- if [ $? -ne 0 ]; then
- failed "$GITCMD $1 $2"
- fi
+ rtn=$?
cd $old_pwd
- if [ X"$BUILD_ONE" != X ]; then
- echo "Single-component git command complete"
- exit 0
+ if [ $rtn -ne 0 ]; then
+ failed "$GITCMD" $1 $2
+ return 1
fi
return 0
fi
if [ X"$PULL" != X ]; then
- git pull --rebase || failed "git pull" $1 $2
+ git pull --rebase
+ if [ $? -ne 0 ]; then
+ failed "git pull" $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
# Build outside source directory
if [ X"$DIR_ARCH" != X ] ; then
- mkdir -p "$DIR_ARCH" || failed mkdir $1 $2
- if cd "$DIR_ARCH" ; then :; else
+ mkdir -p "$DIR_ARCH"
+ if [ $? -ne 0 ]; then
+ failed mkdir $1 $2
+ cd $old_pwd
+ return 1
+ fi
+ cd "$DIR_ARCH"
+ if [ $? -ne 0 ]; then
failed cd2 $1 $2
cd ${old_pwd}
- return
+ return 1
fi
fi
if [ X"$MAKECMD" != X ]; then
- $MAKECMD || failed "$MAKECMD" $1 $2
+ $MAKECMD
+ if [ $? -ne 0 ]; then
+ failed "$MAKECMD" $1 $2
+ cd $old_pwd
+ return 1
+ fi
else
# Special configure flags for certain modules
MOD_SPECIFIC=
@@ -290,27 +294,92 @@ build() {
if [ X"$NOAUTOGEN" = X ]; then
sh ${DIR_CONFIG}/${CONFCMD} --prefix=${PREFIX} ${LIB_FLAGS} \
${MOD_SPECIFIC} ${QUIET:+--quiet} \
- ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} "$CONFCFLAGS" || \
+ ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} "$CONFCFLAGS"
+ if [ $? -ne 0 ]; then
failed ${CONFCMD} $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
- ${MAKE} $MAKEFLAGS || failed make $1 $2
+
+ ${MAKE} $MAKEFLAGS
+ if [ $? -ne 0 ]; then
+ failed make $1 $2
+ cd $old_pwd
+ return 1
+ fi
+
if [ X"$CHECK" != X ]; then
- ${MAKE} $MAKEFLAGS check || failed check $1 $2
+ ${MAKE} $MAKEFLAGS check
+ if [ $? -ne 0 ]; then
[PATCH modular 04/10] Document functions in build.sh.
From: Trevor Woerner
Provide explanations of functioning and behaviour for some of the functions
in build.sh script.
Signed-off-by: Trevor Woerner
---
build.sh | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/build.sh b/build.sh
index 2bfcebb..07cdea0 100755
--- a/build.sh
+++ b/build.sh
@@ -65,6 +65,13 @@ failed_components=""
nonexistent_components=""
clonefailed_components=""
+# explain where a failured occurred
+# if you find this message in the build output it can help tell you where the
failure occurred
+# arguments:
+# $1 - which command failed
+# $2/$3 - which module/component failed
+# returns:
+# (irrelevant)
failed() {
echo "* $1 failed on $2/$3"
failed_components="$failed_components $2/$3"
@@ -157,6 +164,15 @@ checkfortars() {
return 0
}
+# perform a clone of a git repository
+# this function provides the mapping between module/component names
+# and their location in the fd.o repository
+# arguments:
+# $1 - module
+# $2 - component (optional)
+# returns:
+# 0 - good
+# 1 - bad
clone() {
case $1 in
"pixman")
@@ -192,6 +208,13 @@ clone() {
return 0
}
+# perform processing of each module/component
+# arguments:
+# $1 - module
+# $2 - component (optional)
+# returns:
+# 0 - good
+# 1 - bad
process() {
local rtn
@@ -357,6 +380,14 @@ process() {
return 0
}
+# process each module/component and handle:
+# LISTONLY, RESUME, NOQUIT, and BUILD_ONE
+# arguments:
+# $1 - module
+# $2 - component (optional)
+# returns:
+# 0 - good
+# 1 - bad
build() {
if [ X"$LISTONLY" != X ]; then
echo "$1/$2"
--
1.7.3.1.45.g9855b
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 05/10] Add preconditions.
From: Trevor Woerner
Provide preconditions for some of the functions in build.sh script.
Signed-off-by: Trevor Woerner
---
build.sh | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/build.sh b/build.sh
index 07cdea0..5be2337 100755
--- a/build.sh
+++ b/build.sh
@@ -174,6 +174,12 @@ checkfortars() {
# 0 - good
# 1 - bad
clone() {
+# preconds
+if [ X"$1" = X ]; then
+ echo "clone() required argument \$1 missing"
+ return 1
+fi
+
case $1 in
"pixman")
BASEDIR=""
@@ -218,6 +224,12 @@ clone() {
process() {
local rtn
+# preconds
+if [ X"$1" = X ]; then
+ echo "process() required argument \$1 missing"
+ return 1
+fi
+
module_title $1 $2
SRCDIR=""
--
1.7.3.1.45.g9855b
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 06/10] Indentation cleanup.
From: Trevor Woerner
Return early so large portions of code do not need to be indented.
Signed-off-by: Trevor Woerner
---
build.sh | 115 --
1 files changed, 59 insertions(+), 56 deletions(-)
diff --git a/build.sh b/build.sh
index 5be2337..eb1228f 100755
--- a/build.sh
+++ b/build.sh
@@ -307,87 +307,90 @@ process() {
if [ X"$MAKECMD" != X ]; then
$MAKECMD
- if [ $? -ne 0 ]; then
+ rtn=$?
+ cd $old_pwd
+
+ if [ $rtn -ne 0 ]; then
failed "$MAKECMD" $1 $2
- cd $old_pwd
return 1
fi
-else
- # Special configure flags for certain modules
- MOD_SPECIFIC=
+ return 0
+fi
- if [ X"$1" = X"lib" ] && [ X"$2" = X"libX11" ] && [ X"${USE_XCB}" =
X"NO" ]; then
- MOD_SPECIFIC="--with-xcb=no"
- fi
+# Special configure flags for certain modules
+MOD_SPECIFIC=
- LIB_FLAGS=
- if [ X"$LIBDIR" != X ]; then
- LIB_FLAGS="--libdir=${PREFIX}/${LIBDIR}"
- fi
+if [ X"$1" = X"lib" ] && [ X"$2" = X"libX11" ] && [ X"${USE_XCB}" = X"NO"
]; then
+ MOD_SPECIFIC="--with-xcb=no"
+fi
- # Use "sh autogen.sh" since some scripts are not executable in CVS
- if [ X"$NOAUTOGEN" = X ]; then
- sh ${DIR_CONFIG}/${CONFCMD} --prefix=${PREFIX} ${LIB_FLAGS} \
- ${MOD_SPECIFIC} ${QUIET:+--quiet} \
- ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} "$CONFCFLAGS"
- if [ $? -ne 0 ]; then
- failed ${CONFCMD} $1 $2
- cd $old_pwd
- return 1
- fi
- fi
+LIB_FLAGS=
+if [ X"$LIBDIR" != X ]; then
+ LIB_FLAGS="--libdir=${PREFIX}/${LIBDIR}"
+fi
- ${MAKE} $MAKEFLAGS
+# Use "sh autogen.sh" since some scripts are not executable in CVS
+if [ X"$NOAUTOGEN" = X ]; then
+ sh ${DIR_CONFIG}/${CONFCMD} --prefix=${PREFIX} ${LIB_FLAGS} \
+ ${MOD_SPECIFIC} ${QUIET:+--quiet} \
+ ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} "$CONFCFLAGS"
if [ $? -ne 0 ]; then
- failed make $1 $2
+ failed ${CONFCMD} $1 $2
cd $old_pwd
return 1
fi
+fi
- if [ X"$CHECK" != X ]; then
- ${MAKE} $MAKEFLAGS check
- if [ $? -ne 0 ]; then
- failed check $1 $2
- cd $old_pwd
- return 1
- fi
- fi
+${MAKE} $MAKEFLAGS
+if [ $? -ne 0 ]; then
+ failed make $1 $2
+ cd $old_pwd
+ return 1
+fi
- if [ X"$CLEAN" != X ]; then
- ${MAKE} $MAKEFLAGS clean
- if [ $? -ne 0 ]; then
- failed clean $1 $2
- cd $old_pwd
- return 1
- fi
+if [ X"$CHECK" != X ]; then
+ ${MAKE} $MAKEFLAGS check
+ if [ $? -ne 0 ]; then
+ failed check $1 $2
+ cd $old_pwd
+ return 1
fi
+fi
- if [ X"$DIST" != X ]; then
- ${MAKE} $MAKEFLAGS dist
- if [ $? -ne 0 ]; then
- failed dist $1 $2
- cd $old_pwd
- return 1
- fi
+if [ X"$CLEAN" != X ]; then
+ ${MAKE} $MAKEFLAGS clean
+ if [ $? -ne 0 ]; then
+ failed clean $1 $2
+ cd $old_pwd
+ return 1
fi
+fi
- if [ X"$DISTCHECK" != X ]; then
- ${MAKE} $MAKEFLAGS distcheck
- if [ $? -ne 0 ]; then
- failed distcheck $1 $2
- cd $old_pwd
- return 1
- fi
+if [ X"$DIST" != X ]; then
+ ${MAKE} $MAKEFLAGS dist
+ if [ $? -ne 0 ]; then
+ failed dist $1 $2
+ cd $old_pwd
+ return 1
fi
+fi
- $SUDO env LD_LIBRARY_PATH=$LD_LIBRARY_PATH ${MAKE} $MAKEFLAGS install
+if [ X"$DISTCHECK" != X ]; then
+ ${MAKE} $MAKEFLAGS distcheck
if [ $? -ne 0 ]; then
- failed install $1 $2
+ failed distcheck $1 $2
cd $old_pwd
return 1
fi
fi
+$SUDO env LD_LIBRARY_PATH=$LD_LIBRARY_PATH ${MAKE} $MAKEFLAGS install
+if [ $? -ne 0 ]; then
+ failed install $1 $2
+ cd $old_pwd
+ return 1
+fi
+
cd ${old_pwd}
return 0
}
--
1.7.3.1.45.g9855b
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 07/10] Whitespace cleanup.
From: Trevor Woerner
Offset case options so they are visually at a different level than
the actions they cause. Adjust them to match the existing case
statements in the main body of the script.
Signed-off-by: Trevor Woerner
---
build.sh | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/build.sh b/build.sh
index eb1228f..8ee100e 100755
--- a/build.sh
+++ b/build.sh
@@ -181,19 +181,19 @@ clone() {
fi
case $1 in
-"pixman")
+"pixman")
BASEDIR=""
;;
-"xcb")
+"xcb")
BASEDIR=""
;;
-"mesa")
+"mesa")
BASEDIR=""
;;
-"xkeyboard-config")
+"xkeyboard-config")
BASEDIR=""
;;
-*)
+*)
BASEDIR="xorg/"
;;
esac
--
1.7.3.1.45.g9855b
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 08/10] Clean up "clone" logic.
From: Trevor Woerner
Only if cloning succeeds, set SRCDIR and CONFCMD. If SRCDIR is later
discovered the be empty the module can't be processed.
Signed-off-by: Trevor Woerner
---
build.sh | 13 ++---
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/build.sh b/build.sh
index 8ee100e..ae7d34e 100755
--- a/build.sh
+++ b/build.sh
@@ -204,10 +204,12 @@ clone() {
if [ ! -d "$DIR" ]; then
git clone "$GITROOT/$BASEDIR$DIR" "$DIR"
if [ $? -ne 0 ] && [ ! -d "$DIR" ]; then
+echo "Failed to clone $1 module component $2. Ignoring."
+clonefailed_components="$clonefailed_components $1/$2"
return 1
fi
else
-# git cannot clone into an existing directory
+echo "git cannot clone into an existing directory $1/$2"
return 1
fi
@@ -239,13 +241,10 @@ process() {
CONFCMD="autogen.sh"
elif [ X"$CLONE" != X ]; then
clone $1 $2
-if [ $? -ne 0 ]; then
-echo "Failed to clone $1 module component $2. Ignoring."
-clonefailed_components="$clonefailed_components $1/$2"
-return 1
+if [ $? -eq 0 ]; then
+ SRCDIR="$1/$2"
+ CONFCMD="autogen.sh"
fi
-SRCDIR="$1/$2"
-CONFCMD="autogen.sh"
else
checkfortars $1 $2
CONFCMD="configure"
--
1.7.3.1.45.g9855b
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 09/10] Rely on "git clone" return value.
From: Trevor Woerner
Don't allow the "git clone" to succeed if a partial clone occurs
(i.e. hangup).
Signed-off-by: Trevor Woerner
---
build.sh |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/build.sh b/build.sh
index ae7d34e..a427b57 100755
--- a/build.sh
+++ b/build.sh
@@ -203,7 +203,7 @@ clone() {
if [ ! -d "$DIR" ]; then
git clone "$GITROOT/$BASEDIR$DIR" "$DIR"
-if [ $? -ne 0 ] && [ ! -d "$DIR" ]; then
+if [ $? -ne 0 ]; then
echo "Failed to clone $1 module component $2. Ignoring."
clonefailed_components="$clonefailed_components $1/$2"
return 1
--
1.7.3.1.45.g9855b
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 10/10] Provide nicer failed component listing.
From: Trevor Woerner Signed-off-by: Trevor Woerner --- build.sh | 12 +--- 1 files changed, 9 insertions(+), 3 deletions(-) diff --git a/build.sh b/build.sh index a427b57..6c63cc5 100755 --- a/build.sh +++ b/build.sh @@ -1033,21 +1033,27 @@ date if [ X"$nonexistent_components" != X ]; then echo "" echo "* Skipped components (not available) *" -echo "$nonexistent_components" +for mod in $nonexistent_components; do + echo "$mod" +done echo "" fi if [ X"$failed_components" != X ]; then echo "" echo "* Failed components *" -echo "$failed_components" +for mod in $failed_components; do + echo "$mod" +done echo "" fi if [ X"$CLONE" != X ] && [ X"$clonefailed_components" != X ]; then echo "" echo "* Components failed to clone *" -echo "$clonefailed_components" +for mod in $clonefailed_components; do + echo "$mod" +done echo "" fi -- 1.7.3.1.45.g9855b ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] xfree86: fix VbeModeInfoBlock memcpy off-by-one (#30159)
Le 28/09/2010 17:16, Adam Jackson a écrit : > It's correct but it's exactly as ridiculous as the original. How's this > instead: ♥ ! Although... > --- a/hw/xfree86/vbe/vbe.c > +++ b/hw/xfree86/vbe/vbe.c > @@ -529,67 +529,7 @@ VBEGetModeInfo(vbeInfoPtr pVbe, int mode) > > block = calloc(sizeof(VbeModeInfoBlock), 1); ... maybe this one can become a regular malloc(), since the structure is packed and the copy covers the entire struct, there won't be any uninitialized holes. [...] > +memcpy(block, pVbe->memory, 256); Just wondering, why not use sizeof here as well? Am I missing something? In any case, the new patch makes a whole lot more sense than the old code, I still can't believe it was that simple. I'll gladly update your patch if needs be. Reviewed-by: Rémi Cardona Cheers ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X input event generation thread (v2)
Adam Jackson wrote: > On Tue, 2010-09-28 at 23:00 +0200, Mark Kettenis wrote: >> Of course the same problem exists with SIGIO. After realizing how >> much code was run from the SIGIO signal handler, and the VGA arbiter >> issues related to that we decided to disable SIGIO on OpenBSD >> (encouraged by Alan C.'s statement that Solaris does the same). As >> far as I can tell, the only effect of this is that it disables the >> "silken mouse". Quite a few OpenBSD users tested that change, and all >> of them indicated that they noticed no difference whatsoever. > > Your users are clearly not sensitive to input latency. Mine are. My users were used to not having SIGIO, since we disabled SIGIO within a couple months of first delivering a version that actually had a Solaris implentation. We also have a very different kernel scheduler - I don't know how much that affects things. Certainly in years past, this sort of thing was important to Sun, since we had a kernel level implementation in Solaris on SPARC, but that required kernel frame buffer devices implementing a common set of hardware cursor ioctls that we could call to move the pointer image from a streams module pushed onto the mouse device, bypassing the server altogether until you crossed out of the bounding rectangle passed down by the server. But that was the days when users had 25Mhz SPARC cpu's, not 2.5 Ghz x64. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 01/10] Provide visual separation between modules.
On Thu, 2010-09-30 at 17:25 -0400, Trevor Woerner wrote: > From: Trevor Woerner > > When reviewing a build log or watching a build, it is easier to see > which > module/component is being processed at arbitrary points if a clear, > visual > separation exists between the processing of each module/component. > > Signed-off-by: Trevor Woerner > --- > build.sh | 18 +- > 1 files changed, 17 insertions(+), 1 deletions(-) > Reviewed-by: Gaetan Nadon signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 02/10] Provide earlier module/component title.
On Thu, 2010-09-30 at 17:26 -0400, Trevor Woerner wrote: > From: Trevor Woerner > > I would like to see the module/component title appear > before the configuration/clone step. > > Signed-off-by: Trevor Woerner > --- > build.sh |4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > Reviewed-by: Gaetan Nadon signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH modular 03/10] Centralize build mode logic.
On Thu, 2010-09-30 at 17:26 -0400, Trevor Woerner wrote:
> From: Trevor Woerner
>
> Place into one location the logic to decide what to do with regards to
> the following build modes: LISTONLY, RESUME, NOQUIT, and BUILD_ONE.
>
> Signed-off-by: Trevor Woerner
> ---
> build.sh | 163
> --
> 1 files changed, 116 insertions(+), 47 deletions(-)
>
> diff --git a/build.sh b/build.sh
> index 3a57561..2bfcebb 100755
> --- a/build.sh
> +++ b/build.sh
> @@ -66,12 +66,8 @@ nonexistent_components=""
> clonefailed_components=""
>
> failed() {
> -if [ X"${NOQUIT}" != X ]; then
> - echo "* $1 failed on $2/$3"
> - failed_components="$failed_components $2/$3"
> -else
> - exit 1
> -fi
> +echo "* $1 failed on $2/$3"
> +failed_components="$failed_components $2/$3"
> }
>
> # print a pretty title to separate the processing of each module
> @@ -147,12 +143,18 @@ checkfortars() {
> if [ X"$jj" = X"gz" ]; then
> TAROPTS=xzf
> fi
> -tar $TAROPTS $TARFILE -C $ii || failed tar $1 $2
> +tar $TAROPTS $TARFILE -C $ii
> + if [ $? -ne 0 ]; then
> + failed tar $1 $2
> + return 1
> + fi
>
I got distracted by this "return 1" change and there are quite a few of
them.
Could you split the patch to take this change out of way as it does not
match the commit text.
It would significantly reduce the size of the main patch.
A random example where the code change is not related to (but of course,
necessary) to
the code mission of the patch. I know it's not always possible, I am not
sure in this case, that's why I ask.
signature.asc
Description: This is a digitally signed message part
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [DOC] Re: java OutOfMemory building documentation
Also of note... My G5 took an hour and a half just to 'make install' with these changes. It looks like it's redoing some things in 'make install' that it already did in 'make': http://tinderbox.x.org/builds/2010-09-30-0022/ On Sep 29, 2010, at 09:31, Alan Coopersmith wrote: Matt Dew wrote: On Wed, Sep 29, 2010 at 9:41 AM, Younes Manton wrote: On Wed, Sep 29, 2010 at 2:25 AM, Jeremy Huddleston > wrote: This change seems to be causing documentation to fail building on yuffie due to java running out of memory… http://tinderbox.x.org/builds/2010-09-22-0004/logs/libX11/#build I seem to recall other "OutOfMemory" errors being reported wrt documentation earlier, but I don't recall any resolution. Looking at fop, it looks like we can setup a FOP_OPTS environment variable with an appropriate - Xmx argument to be passed along to java. I just tested this on yuffie by adding the following to my tinderbox script, and it resolved my build failure: export FOP_OPTS="-Xmx2048m" Obviously setting the max VM size as 2G universally isn't the best solution. I also don't expect everyone to know about FOPS_OPTS either, so what is the best way to resolve this across modules? It's not a terrible solution, it's not like you'll actually be using 2G on any halfway sane jvm except when you need it, it's just an upper bound. FWIW, libX11 is the largest document and I found that using export FOP_OPTS="-Xmx512m" was sufficient. The new documents I autogenerate from the Compose data files have some very large tables in, most especially the en_US.UTF-8 compose key list - I'd set them to split into new tables after 750 lines since that solved the java out-of-memory issues in my environment, but it appears not to solve it for everyone - the script can be adjusted to split at a different threshold if that's easier than trying to find a way to set FOP_OPTS in the Makefile.am's. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 03a/10] Centralize build mode logic.
From: Trevor Woerner
Place into one location the logic to decide what to do with regards to
the following build modes: LISTONLY, RESUME, and BUILD_ONE.
Signed-off-by: Trevor Woerner
---
build.sh | 66 +++--
1 files changed, 38 insertions(+), 28 deletions(-)
diff --git a/build.sh b/build.sh
index 3a57561..7d005e2 100755
--- a/build.sh
+++ b/build.sh
@@ -149,10 +149,12 @@ checkfortars() {
fi
tar $TAROPTS $TARFILE -C $ii || failed tar $1 $2
fi
-return
+return 0
fi
done
done
+
+return 0
}
clone() {
@@ -190,21 +192,8 @@ clone() {
return 0
}
-build() {
-if [ X"$LISTONLY" != X ]; then
- echo "$1/$2"
- return 0
-fi
-
-if [ X"$RESUME" != X ]; then
- if [ X"$RESUME" = X"$1/$2" ]; then
- unset RESUME
- # Resume build at this module
- else
- echo "Skipping $1 module component $2..."
- return 0
- fi
-fi
+process() {
+local rtn
module_title $1 $2
@@ -218,10 +207,7 @@ build() {
if [ $? -ne 0 ]; then
echo "Failed to clone $1 module component $2. Ignoring."
clonefailed_components="$clonefailed_components $1/$2"
-if [ X"$BUILD_ONE" != X ]; then
-exit 1
-fi
-return
+return 1
fi
SRCDIR="$1/$2"
CONFCMD="autogen.sh"
@@ -233,7 +219,7 @@ build() {
if [ X"$SRCDIR" = X ]; then
echo "$1 module component $2 does not exist, skipping."
nonexistent_components="$nonexistent_components $1/$2"
-return
+return 0
fi
if [ X"$BUILT_MODULES_FILE" != X ]; then
@@ -245,14 +231,12 @@ build() {
if [ X"$GITCMD" != X ]; then
$GITCMD
- if [ $? -ne 0 ]; then
- failed "$GITCMD $1 $2"
- fi
+ rtn=$?
cd $old_pwd
- if [ X"$BUILD_ONE" != X ]; then
- echo "Single-component git command complete"
- exit 0
+ if [ $rtn -ne 0 ]; then
+ failed "$GITCMD" $1 $2
+ return 1
fi
return 0
fi
@@ -267,7 +251,7 @@ build() {
if cd "$DIR_ARCH" ; then :; else
failed cd2 $1 $2
cd ${old_pwd}
- return
+ return 1
fi
fi
@@ -311,6 +295,32 @@ build() {
fi
cd ${old_pwd}
+return 0
+}
+
+build() {
+if [ X"$LISTONLY" != X ]; then
+ echo "$1/$2"
+ return 0
+fi
+
+if [ X"$RESUME" != X ]; then
+ if [ X"$RESUME" = X"$1/$2" ]; then
+ unset RESUME
+ # Resume build at this module
+ else
+ echo "Skipping $1 module component $2..."
+ return 0
+ fi
+fi
+
+process $1 $2
+if [ $? -ne 0 ]; then
+ echo "error processing module/component: \"$1/$2\""
+ if [ X"$NOQUIT" = X ]; then
+ exit 1
+ fi
+fi
if [ X"$BUILD_ONE" != X ]; then
echo "Single-component build complete"
--
1.7.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH modular 03b/10] Centralize NOQUIT build mode.
From: Trevor Woerner
Put all the logic to handle the NOQUIT (-n) mode into one location.
Signed-off-by: Trevor Woerner
---
build.sh | 97 +
1 files changed, 78 insertions(+), 19 deletions(-)
diff --git a/build.sh b/build.sh
index 7d005e2..2bfcebb 100755
--- a/build.sh
+++ b/build.sh
@@ -66,12 +66,8 @@ nonexistent_components=""
clonefailed_components=""
failed() {
-if [ X"${NOQUIT}" != X ]; then
- echo "* $1 failed on $2/$3"
- failed_components="$failed_components $2/$3"
-else
- exit 1
-fi
+echo "* $1 failed on $2/$3"
+failed_components="$failed_components $2/$3"
}
# print a pretty title to separate the processing of each module
@@ -147,7 +143,11 @@ checkfortars() {
if [ X"$jj" = X"gz" ]; then
TAROPTS=xzf
fi
-tar $TAROPTS $TARFILE -C $ii || failed tar $1 $2
+tar $TAROPTS $TARFILE -C $ii
+ if [ $? -ne 0 ]; then
+ failed tar $1 $2
+ return 1
+ fi
fi
return 0
fi
@@ -227,7 +227,11 @@ process() {
fi
old_pwd=`pwd`
-cd $SRCDIR || failed cd1 $1 $2
+cd $SRCDIR
+if [ $? -ne 0 ]; then
+ failed cd1 $1 $2
+ return 1
+fi
if [ X"$GITCMD" != X ]; then
$GITCMD
@@ -242,13 +246,24 @@ process() {
fi
if [ X"$PULL" != X ]; then
- git pull --rebase || failed "git pull" $1 $2
+ git pull --rebase
+ if [ $? -ne 0 ]; then
+ failed "git pull" $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
# Build outside source directory
if [ X"$DIR_ARCH" != X ] ; then
- mkdir -p "$DIR_ARCH" || failed mkdir $1 $2
- if cd "$DIR_ARCH" ; then :; else
+ mkdir -p "$DIR_ARCH"
+ if [ $? -ne 0 ]; then
+ failed mkdir $1 $2
+ cd $old_pwd
+ return 1
+ fi
+ cd "$DIR_ARCH"
+ if [ $? -ne 0 ]; then
failed cd2 $1 $2
cd ${old_pwd}
return 1
@@ -256,7 +271,12 @@ process() {
fi
if [ X"$MAKECMD" != X ]; then
- $MAKECMD || failed "$MAKECMD" $1 $2
+ $MAKECMD
+ if [ $? -ne 0 ]; then
+ failed "$MAKECMD" $1 $2
+ cd $old_pwd
+ return 1
+ fi
else
# Special configure flags for certain modules
MOD_SPECIFIC=
@@ -274,24 +294,63 @@ process() {
if [ X"$NOAUTOGEN" = X ]; then
sh ${DIR_CONFIG}/${CONFCMD} --prefix=${PREFIX} ${LIB_FLAGS} \
${MOD_SPECIFIC} ${QUIET:+--quiet} \
- ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} "$CONFCFLAGS" || \
+ ${CACHE:+--cache-file=}${CACHE} ${CONFFLAGS} "$CONFCFLAGS"
+ if [ $? -ne 0 ]; then
failed ${CONFCMD} $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
- ${MAKE} $MAKEFLAGS || failed make $1 $2
+
+ ${MAKE} $MAKEFLAGS
+ if [ $? -ne 0 ]; then
+ failed make $1 $2
+ cd $old_pwd
+ return 1
+ fi
+
if [ X"$CHECK" != X ]; then
- ${MAKE} $MAKEFLAGS check || failed check $1 $2
+ ${MAKE} $MAKEFLAGS check
+ if [ $? -ne 0 ]; then
+ failed check $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
+
if [ X"$CLEAN" != X ]; then
- ${MAKE} $MAKEFLAGS clean || failed clean $1 $2
+ ${MAKE} $MAKEFLAGS clean
+ if [ $? -ne 0 ]; then
+ failed clean $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
+
if [ X"$DIST" != X ]; then
- ${MAKE} $MAKEFLAGS dist || failed dist $1 $2
+ ${MAKE} $MAKEFLAGS dist
+ if [ $? -ne 0 ]; then
+ failed dist $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
+
if [ X"$DISTCHECK" != X ]; then
- ${MAKE} $MAKEFLAGS distcheck || failed distcheck $1 $2
+ ${MAKE} $MAKEFLAGS distcheck
+ if [ $? -ne 0 ]; then
+ failed distcheck $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
- $SUDO env LD_LIBRARY_PATH=$LD_LIBRARY_PATH ${MAKE} $MAKEFLAGS install
|| \
+
+ $SUDO env LD_LIBRARY_PATH=$LD_LIBRARY_PATH ${MAKE} $MAKEFLAGS install
+ if [ $? -ne 0 ]; then
failed install $1 $2
+ cd $old_pwd
+ return 1
+ fi
fi
cd ${old_pwd}
--
1.7.3
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [xserver patch] remove dolt
On Thu, 30 Sep 2010 13:18:20 +0300, Adrian Bunk wrote: > With libtool 2.2.10 the difference in build time is so small > (< 5% with -j8 builds) that it isn't worth having this hack. > > Signed-off-by: Adrian Bunk Applied. c7e4222..a769f4c master -> master -- keith.pack...@intel.com pgpGtF0Fbdy2k.pgp Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
