Re: [PATCH macros v2] Fix XORG_WITH_XMLTO to work with xmlto >= 0.0.27
On 16-01-12 07:59 AM, Andreas Boll wrote: > Starting with xmlto version 0.0.27 the return code of > xmlto --skip-validation txt conftest.xml > is non-zero if conftest.xml is an empty file. > > As a consequence the macro XORG_WITH_XMLTO returns > "xmlto cannot generate text format, this format skipped" > and therefore libraries like libxi, libxdmcp and others won't convert > docbook XML to text format. > > This changed behavior was introduced with the following change in xmlto: > xmlto.in: use correctly exit code from xsltproc > See also: https://fedorahosted.org/xmlto/changeset/77 > > This patch fixes this by additionally testing xmlto with a non-empty XML > file. > > More details can be found at: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=613674 > > Thanks to Peter Pearse, Helmut Grohne and Gaetan Nadon. > > v2: To maintain compatibility with older xorg tarballs don't replace > the original test with the empty XML file but instead add a fallback > to additionally test with a non-empty XML file if the original test fails. > Use the alternate solution with to skip compatibility issues > with different docbook versions. > > Cc: Gaetan Nadon <mems...@videotron.ca> > Signed-off-by: Andreas Boll <andreas.boll@gmail.com> > --- > I've successfully tested this patch to build libxi with xmlto 0.0.26, 0.0.27 > and 0.0.28. > > To test this patch on a platform with only docbook version 5 installed > I've replaced docbook-xml with docbook5-xml. On such a setup the macro > XORG_WITH_XMLTO detects xmlto correctly though it fails later in the build > with: > > xmlto: /«PKGBUILDDIR»/build/man/XAllowDeviceEvents.xml does not validate > (status 3) > xmlto: Fix document syntax or use --skip-validation option > I/O error : Attempt to load network entity > http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd > /«PKGBUILDDIR»/build/man/XAllowDeviceEvents.xml:2: warning: failed to > load external entity > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; > D DocBook XML V4.5//EN" > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; >^ > I/O error : Attempt to load network entity > http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd > warning: failed to load external entity > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; > validity error : Could not load the external subset > "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd; > Document /«PKGBUILDDIR»/build/man/XAllowDeviceEvents.xml does not > validate > > This build failure is expected since docbook version 5 is not backward > compatible to version 4 and XORG_WITH_XMLTO doesn't check for a specific > docbook version. > > xorg-macros.m4.in | 13 - > 1 file changed, 12 insertions(+), 1 deletion(-) Reviewed-by: Gaetan Nadon <mems...@videotron.ca> I am no longer subscribed to the list ___ 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 RFC macros] Fix XORG_WITH_XMLTO to work with xmlto >= 0.0.27
On 15-12-10 03:08 PM, Andreas Boll wrote: > @Gaetan: > Do you still have a concern on the patch? > >> > The one thing that bugs me about the patch is that the version of >> > docbook may eventually be >> > no longer available and this macro must remain backward compatible for >> > eternity. > An alternate solution suggested by Helmut Grohne would be to simply add > into conftest.xml. I haven't touched this for years, but I noticed that backward compatibility with older versions of docbook is provided by the platform. I recall seeing some errors when a book required version 4.3, for example, could not be found because the latest installed version of docbook was 4.1. On the other end, I think requiring an older version (4.1 when 4.3 is installed) should cause no errors as platforms redirect the older version to the newer version of docbook as the platform wants to be backwards compatible. Note that only "point" versions are backward compatible, like 4.1 and 4.3, not 4.3 and 5.0. Version 5 is not backward compatible to version 4. However a simple document should work regardless. To be sure, one can test requesting a 4.3 document on a later platform where only version 5 is installed. The alternate solution seems ok. It should be tested on both version 4 and 5. It skips all the compatibility issues which are very difficult to sort out. That would save on service cost. For the xorg macro itself to remain backward compatible, I would suggest you keep the actual test, but if it fails, perform the new test you suggest (either the well formed 4.3 docbook or the ). This way we are certain not to introduce problems in older (very old) xorg tarballs that are compiled with the newer version of the xorg-macro. That's why the xorg macros must remain backward compatible for eternity. ___ 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 util-modular 1/3] xorg.modules: Add libevdev requirement to synaptics
On 15-03-15 06:47 PM, Peter Hutterer wrote: Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- xorg.modules | 1 + 1 file changed, 1 insertion(+) diff --git a/xorg.modules b/xorg.modules index 7216192..6d80c6b 100644 --- a/xorg.modules +++ b/xorg.modules @@ -1974,6 +1974,7 @@ dep package=libX11/ dep package=libXi/ dep package=xserver/ + dep package=libevdev/ /dependencies /autotools Should we not preserve the comment as well? Unless of course it was wrong in the first place. This helps those customizing the list and saves them from debugging build problems on non Linux platforms. - dep package=libevdev/ !-- Linux Only -- ___ 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 app-xinit 0/3] Clean-up some dead code left by previous patches
Gaetan Nadon (3): Remove SCO support for SHELL_CMD and startx man page. Remove support for ancient A/UX 3.0 support Remove left over $(launchagents_DATA) in CLEANFILES Makefile.am | 2 +- configure.ac| 5 - man/Makefile.am | 1 - man/startx.man | 15 --- startx.cpp | 5 - 5 files changed, 1 insertion(+), 27 deletions(-) -- 1.9.1 ___ 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 app-xinit 1/3] Remove SCO support for SHELL_CMD and startx man page.
SCO support was removed from startx.cpp and xinitrc.cpp earlier. Remove unixware / sco support http://cgit.freedesktop.org/xorg/app/xinit/commit/ ?id=fdf03cd2fdfd9cd5635334c5e4dc2bb23e92e37a Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac| 5 - man/Makefile.am | 1 - man/startx.man | 26 -- 3 files changed, 32 deletions(-) diff --git a/configure.ac b/configure.ac index 18794b3..461648b 100644 --- a/configure.ac +++ b/configure.ac @@ -190,13 +190,8 @@ case $host_os in *solaris*) SHELL_CMD=/bin/ksh ;; -*sco*) - SHELL_CMD=/bin/ksh - SCOMAN=1 - ;; esac AC_SUBST(SHELL_CMD) -AC_SUBST(SCOMAN) AC_SUBST(XSERVERNAME) AC_SUBST(XCONFIGFILE) AC_SUBST(XCONFIGFILEMAN) diff --git a/man/Makefile.am b/man/Makefile.am index b24faca..9c6569f 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -13,7 +13,6 @@ MAN_SUBSTS+= -e 's|__XSERVERNAME__|$(XSERVERNAME)|g' \ -e 's|__xinitdir__|$(XINITDIR)|g' \ -e 's|__bindir__|$(bindir)|g' \ -e 's|__libdir__|$(libdir)|g' \ - -e 's|__SCOMAN__|$(SCOMAN)|g' \ -e 's|__configdir__|$(XINITDIR)|g' diff --git a/man/startx.man b/man/startx.man index 0405be0..4728a25 100644 --- a/man/startx.man +++ b/man/startx.man @@ -74,7 +74,6 @@ startx -- -dpi 100 .PP startx -- -layout Multihead .RE -.if '__SCOMAN__'' .ig .PP To determine the client to run, .B startx @@ -90,20 +89,6 @@ looks for the following files, in order: .I __xinitdir__/xinitrc .RE .PP -.. -.if !'x.__SCOMAN__'x.' .ig -.PP -To determine the client to run, -.B startx -first looks for a file called -.I .xinitrc -in the user's home directory. If that is not found, it uses -the file -.I xinitrc -in the -.I xinit -library directory. -.. If command line client options are given, they override this behavior and revert to the .BR xinit (__appmansuffix__) @@ -187,17 +172,6 @@ and .IR Xsecurity (__miscmansuffix__) manual pages for more information on X client/server authentication. .SH FILES -.if '__SCOMAN__'' .ig -.TP 25 -.I $(HOME)/.startxrc -Client to run. Typically a shell script which runs many programs in -the background. -.TP 25 -.I __libdir__/sys.startxrc -Client to use if the user has no -.I .startxrc -file. -.. .TP 25 .I $(HOME)/.xinitrc Client to run. Typically a shell script which runs many programs in -- 1.9.1 ___ 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 app-xinit 2/3] Remove support for ancient A/UX 3.0 support
This was Apple Computer’s implementation of the Unix operating system for some of their Macintosh computers. From 1988 to 1995. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- startx.cpp | 5 - 1 file changed, 5 deletions(-) diff --git a/startx.cpp b/startx.cpp index ce4713f..8520399 100644 --- a/startx.cpp +++ b/startx.cpp @@ -326,11 +326,6 @@ if command -v deallocvt /dev/null 21; then fi #endif -#ifdef macII -Xrepair -screenrestore -#endif - #if defined(sun) kbd_mode -a #endif -- 1.9.1 ___ 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 app-xinit 3/3] Remove left over $(launchagents_DATA) in CLEANFILES
This was left over when reorganizing layout of launchd sources in commit 567f59d3f8189b92bc46e2af1260f9340f462bdb Signed-off-by: Gaetan Nadon mems...@videotron.ca --- Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile.am b/Makefile.am index 3867bea..c1eb5a9 100644 --- a/Makefile.am +++ b/Makefile.am @@ -58,7 +58,7 @@ CPP_FILES_FLAGS = \ xinitrc_DATA = xinitrc MAINTAINERCLEANFILES = ChangeLog INSTALL -CLEANFILES = xinitrc startx $(launchagents_DATA) +CLEANFILES = xinitrc startx EXTRA_DIST = xinitrc.cpp startx.cpp \ autogen.sh -- 1.9.1 ___ 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 app-xinit 1/3] Remove SCO support for SHELL_CMD and startx man page.
SCO support was removed from startx.cpp and xinitrc.cpp earlier. Remove unixware / sco support http://cgit.freedesktop.org/xorg/app/xinit/commit/ ?id=fdf03cd2fdfd9cd5635334c5e4dc2bb23e92e37a Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac| 5 - man/Makefile.am | 1 - man/startx.man | 15 --- 3 files changed, 21 deletions(-) diff --git a/configure.ac b/configure.ac index 18794b3..461648b 100644 --- a/configure.ac +++ b/configure.ac @@ -190,13 +190,8 @@ case $host_os in *solaris*) SHELL_CMD=/bin/ksh ;; -*sco*) - SHELL_CMD=/bin/ksh - SCOMAN=1 - ;; esac AC_SUBST(SHELL_CMD) -AC_SUBST(SCOMAN) AC_SUBST(XSERVERNAME) AC_SUBST(XCONFIGFILE) AC_SUBST(XCONFIGFILEMAN) diff --git a/man/Makefile.am b/man/Makefile.am index b24faca..9c6569f 100644 --- a/man/Makefile.am +++ b/man/Makefile.am @@ -13,7 +13,6 @@ MAN_SUBSTS+= -e 's|__XSERVERNAME__|$(XSERVERNAME)|g' \ -e 's|__xinitdir__|$(XINITDIR)|g' \ -e 's|__bindir__|$(bindir)|g' \ -e 's|__libdir__|$(libdir)|g' \ - -e 's|__SCOMAN__|$(SCOMAN)|g' \ -e 's|__configdir__|$(XINITDIR)|g' diff --git a/man/startx.man b/man/startx.man index 0405be0..03e15a9 100644 --- a/man/startx.man +++ b/man/startx.man @@ -74,7 +74,6 @@ startx -- -dpi 100 .PP startx -- -layout Multihead .RE -.if '__SCOMAN__'' .ig .PP To determine the client to run, .B startx @@ -90,20 +89,6 @@ looks for the following files, in order: .I __xinitdir__/xinitrc .RE .PP -.. -.if !'x.__SCOMAN__'x.' .ig -.PP -To determine the client to run, -.B startx -first looks for a file called -.I .xinitrc -in the user's home directory. If that is not found, it uses -the file -.I xinitrc -in the -.I xinit -library directory. -.. If command line client options are given, they override this behavior and revert to the .BR xinit (__appmansuffix__) -- 1.9.1 ___ 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: Migrating away from using cpp for startx and xinitrc in xinit
On 15-02-10 10:44 AM, Alan Coopersmith wrote:
Right - build time uses such as startx xinitrc should be replacable
with a bit of work, such as Gaetan did in the past to use sed instead
of cpp on a bunch of man pages.
I had worked on this three years ago. I tried removing the use of cpp as
a text only processor every where I could. I had a prototype of what
startx would look like. One has to watch for built-in compiler defines
auch as __APPLE__ and replaced them with Automake variables such as
$host_os assuming the semantic is the same. See attachment.
On a side note, the following lines should be removed as they are left
over from ancient A/UX 3.0 support.
#ifdef macII
Xrepair
screenrestore
#endif
#!@SHELL_CMD@
#
# This is just a sample implementation of a slightly less primitive
# interface than xinit. It looks for user .xinitrc and .xserverrc
# files, then system xinitrc and xserverrc files, else lets xinit choose
# its default. The system xinitrc should probably do things like check
# for .Xresources files and merge them in, startup up a window manager,
# and pop a clock and serveral xterms.
#
# Site administrators are STRONGLY urged to write nicer versions.
#
unset DBUS_SESSION_BUS_ADDRESS
unset SESSION_MANAGER
prefix=@prefix@
exec_prefix=@exec_prefix@
bindir=@bindir@
libdir=@libdir@
host_os=@host_os@
# Check for /usr/bin/X11 and BINDIR in the path, if not add them.
# This allows startx to be placed in a place like /usr/bin or /usr/local/bin
# and people may use X without changing their PATH.
# Note that we put our own bin directory at the front of the path, and
# the standard system path at the back, since if you are using the Xorg
# server theres a pretty good chance you want to bias the Xorg clients
# over the old system's clients.
case $host_os in
*sco* | darwin*)
# First our compiled path
case $PATH in
*:$bindir | *:$bindir:* | $bindir:*) ;;
*) PATH=$bindir:$PATH ;;
esac
# Now the old compiled path
case $host_os in
darwin*)
oldbindir=/usr/X11R6/bin
;;
*)
oldbindir=/usr/bin/X11
;;
esac
if [ -d $oldbindir ] ; then
case $PATH in
*:$oldbindir | *:$oldbindir:* | $oldbindir:*) ;;
*) PATH=$PATH:$oldbindir ;;
esac
fi
# Bourne shell does not automatically export modified environment
variables
# so export the new PATH just in case the user changes the shell
export PATH
;;
esac
# Set up the XMERGE env var so that dos merge is happy under X
case $host_os in
*sco*)
if [ -f /usr/lib/merge/xmergeset.sh ]; then
. /usr/lib/merge/xmergeset.sh
elif [ -f /usr/lib/merge/console.disp ]; then
XMERGE=`cat /usr/lib/merge/console.disp`
export XMERGE
fi
userclientrc=$HOME/.startxrc
sysclientrc=${libdir}/sys.startxrc
scouserclientrc=$HOME/.xinitrc
scosysclientrc=@XINITDIR@/xinitrc
;;
*)
userclientrc=$HOME/.xinitrc
sysclientrc=@XINITDIR@/xinitrc
;;
esac
userserverrc=$HOME/.xserverrc
sysserverrc=@XINITDIR@/xserverrc
defaultclient=@XTERM@
defaultserver=@XSERVER@
defaultclientargs=
defaultserverargs=
defaultdisplay=:0
clientargs=
serverargs=
case $host_os in
darwin*)
if [ x$X11_PREFS_DOMAIN = x ] ; then
export X11_PREFS_DOMAIN=@launchdidprefix@.X11
fi
# Initialize defaults (this will cut down on safe error messages)
if ! defaults read $X11_PREFS_DOMAIN cache_fonts /dev/null 21 ; then
defaults write $X11_PREFS_DOMAIN cache_fonts -bool true
fi
if ! defaults read $X11_PREFS_DOMAIN no_auth /dev/null 21 ; then
defaults write $X11_PREFS_DOMAIN no_auth -bool false
fi
if ! defaults read $X11_PREFS_DOMAIN nolisten_tcp /dev/null 21 ;
then
defaults write $X11_PREFS_DOMAIN nolisten_tcp -bool true
fi
# First, start caching fonts
if [ x`defaults read $X11_PREFS_DOMAIN cache_fonts` = x1 ] ; then
if [ -x $bindir/font_cache ] ; then
$bindir/font_cache
elif [ -x $bindir/font_cache.sh ] ; then
$bindir/font_cache.sh
elif [ -x $bindir/fc-cache ] ; then
$bindir/fc-cache
fi
fi
if [ -x @XINITDIR@/privileged_startx ] ; then
# Don't push this into the background becasue it can cause
# a race to create /tmp/.X11-unix
@XINITDIR@/privileged_startx
fi
if [ x`defaults read $X11_PREFS_DOMAIN no_auth` = x0 ] ; then
enable_xauth=1
else
enable_xauth=0
fi
if [ x`defaults read $X11_PREFS_DOMAIN nolisten_tcp` = x1 ] ; then
defaultserverargs=$defaultserverargs -nolisten tcp
Re: [PATCH xorg-fonts] configure.ac: remove C compiler dependency
On 14-12-15 07:54 PM, Alan Coopersmith wrote: On 12/12/14 09:43 AM, Richard Tollerton wrote: Font compilation does not require a C compiler, but configure will fail anyway if one isn't found, because of the inclusion of XORG_DEFAULT_OPTIONS. Fix this by including only those macros normally in XORG_DEFAULT_OPTIONS that don't ultimately bring in AC_PROG_CC. Signed-off-by: Richard Tollerton rich.toller...@ni.com --- configure.ac | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 5b5b3aa..1d6874a 100644 --- a/configure.ac +++ b/configure.ac @@ -31,7 +31,9 @@ AM_INIT_AUTOMAKE([foreign dist-bzip2]) m4_ifndef([XORG_MACROS_VERSION], [m4_fatal([must install xorg-macros 1.3 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.3) -XORG_DEFAULT_OPTIONS +XORG_RELEASE_VERSION +XORG_CHANGELOG +XORG_MANPAGE_SECTIONS I do like the idea of skipping a lot of time-consuming compiler tests when building those modules in a full build, but I'm not sure that's the best way to do it. Instead of undoing XORG_DEFAULT_OPTIONS and going back to updating every configure script for every global change I'd rather we introduced into xorg-macros either an argument to XORG_DEFAULT_OPTIONS to skip the calls that set up compiler flags or have new macro that's the appropriate subset of options for modules that don't use the compiler. For instance, the above is missing XORG_INSTALL, AC_PROG_INSTALL, the setup of AM_SILENT_RULES which all are applied in current XORG_DEFAULT_OPTIONS and are useful for fonts similar modules. There are many modules where the compiler is not required. Other examples are all the X protocol modules. If a computer lacks a compiler, there will be many more modules that will not autoconf successfully. Several years ago it was calculated that the effort to omit compiler configuration from the modules that don't require it was not justified. I agree that if the no compiler configuration was justified, it should be done in the xorg-macros package. Richard should make a case for it. Is there a serious real life problem or was it merely an optimization issue? It could be more work than it first seems. The compiler autoconf process includes other macros for example grep and awk that we don't bother invoking in xorg-macros. These would need to be analyzed and explicitly invoked. I wonder if make distcheck has been tested. It could very well be that having a compiler is a hidden assumption in the autoconf/automake packages. It may also be that some distros pull in the compiler with the autoconf automake packages. ___ 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 util/modular] Add gpg signing to release.sh
On 14-06-07 03:57 PM, Stephen Kitt wrote:
From 283b89da292ad8a5743222baf33393d964cff54b Mon Sep 17 00:00:00 2001
From: Stephen Kitt sk...@debian.org
Date: Sun, 1 Jun 2014 14:46:01 +0200
Subject: [PATCH util/modular] Add gpg signing to release.sh
gpg-sign the git tag and the generated tarballs, and upload the signatures
along with the tarballs. Any existing tarball signatures are removed
beforehand.
Signed-off-by: Stephen Kitt sk...@debian.org
Modified by Alan Coopersmith to handle gpg vs. gpg2 paths for Solaris.
Signed-off-by: Alan Coopersmith alan.coopersm...@oracle.com
---
release.sh | 48 ++--
1 file changed, 46 insertions(+), 2 deletions(-)
diff --git a/release.sh b/release.sh
index a4a725d..6389bc6 100755
--- a/release.sh
+++ b/release.sh
@@ -193,6 +193,29 @@ process_modules() {
}
#--
+# Function: sign_or_fail
+#--
+#
+# Sign the given file, if any
+# Output the name of the signature generated to stdout (all other output to
+# stderr)
+# Return 0 on success, 1 on fail
+#
+sign_or_fail() {
+if [ -n $1 ]; then
+ sig=$1.sig
+ rm -f $sig
+ $GPG -b $1 12
+ if [ $? -ne 0 ]; then
+ echo Error: failed to sign $1. 2
+ return 1
+ fi
+ echo $sig
This echo statement does not appear for me. Perhaps because the function
is called from $(). I do get the gpg message:
You need a passphrase to unlock the secret key for
user: Gaetan Nadon mems...@videotron.ca
1024-bit DSA key, ID FB9EC9FC, created 2008-12-16
Not a big deal,
Reviewed-by: Gaetan Nadonmems...@videotron.ca
___
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 1.5/4 util-modular] release.sh: force /bin/bash
On 14-06-01 11:18 PM, Peter Hutterer wrote: Trying to meet a hard-to-test standard of /bin/sh is unnecessary for a script that's only run by maintainers. For now, simply force bash but don't change any of the script, over time we can update this to support true bashism like [[ ]]. Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- release.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/release.sh b/release.sh index e5774c2..a8d3451 100755 --- a/release.sh +++ b/release.sh @@ -1,4 +1,4 @@ -#!/bin/sh +#!/bin/bash # #Creates and upload a git module tarball # Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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 util-modular 2/4] release.sh: move the bit to extract the section into a function
On 14-05-29 06:24 PM, Peter Hutterer wrote: I was wondering about that, but at least bash --posix was happy with it and I'm struggling how to test pure Bourne shell compatibility. I used http://www.hoomanb.com/cs/QuickRef/bash_ref.pdf when working on build.sh. I got feedback from people running on old systems so it has been working for me. I'd give a big +1 for requiring bash for these scripts. This isn't some super-portable script that needs to run on everything, it's a script that is manually run by a maintainer. And I rather pity the maintainer that can't install a proper shell. I agree (this is not the build.sh script), so as long as the shell requirement is updated in the comment such that anyone maintaining this script knows what it is. I suppose it should also be #!/bin/bash. Perhaps being posix would be a good choice. I am really not an expert in shell script. ___ 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 util-modular 2/4] release.sh: move the bit to extract the section into a function
On 14-05-29 12:51 AM, Peter Hutterer wrote:
No functional changes intended
Signed-off-by: Peter Hutterer peter.hutte...@who-t.net
---
release.sh | 128
+++--
1 file changed, 74 insertions(+), 54 deletions(-)
diff --git a/release.sh b/release.sh
index abfcc29..a05b0c9 100755
--- a/release.sh
+++ b/release.sh
@@ -195,6 +195,63 @@ process_modules() {
#--
#Function: process_module
should be get_section
#--
+# Code 'return 0' on success
+# Code 'return 1' on error
+# Sets global variable $section
+get_section() {
I failed to send my first two replies to the list, sorry.
___
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 1/2] man/Makefile.am: Fix Xorg.wrap.man Xwrapper.config.man missing from make dist
On 14-04-18 05:31 AM, Hans de Goede wrote: Fix suggested by: Gaetan Nadon mems...@videotron.ca Cc: Gaetan Nadon mems...@videotron.ca Signed-off-by: Hans de Goede hdego...@redhat.com --- hw/xfree86/man/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hw/xfree86/man/Makefile.am b/hw/xfree86/man/Makefile.am index f41d26c..5da404c 100644 --- a/hw/xfree86/man/Makefile.am +++ b/hw/xfree86/man/Makefile.am @@ -5,4 +5,6 @@ fileman_PRE = xorg.conf.man xorg.conf.d.man if SUID_WRAPPER appman_PRE += Xorg.wrap.man fileman_PRE += Xwrapper.config.man +else +EXTRA_DIST += Xorg.wrap.man Xwrapper.config.man endif If you have checked the tarballs are identical when configuring with/without suid-wrapper Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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: server make dist not picking up optional manpages
On 14-04-16 10:57 AM, Hans de Goede wrote: Hi All, In hw/xfree86/man/Makefile.am we now have: include $(top_srcdir)/manpages.am appman_PRE = Xorg.man fileman_PRE = xorg.conf.man xorg.conf.d.man if SUID_WRAPPER appman_PRE += Xorg.wrap.man fileman_PRE += Xwrapper.config.man endif And in manpages.am: EXTRA_DIST = $(appman_PRE) $(driverman_PRE) $(fileman_PRE) Normally automake automatically includes build-deps in make dist even if they are in a if ... endif block. But in this case since we conditionally modify a variable and then use that in EXTRA_DIST it seems that make dist is not including Xorg.wrap.man and Xwrapper.config.man (as can been seen in the xorg-server-1.15.99.902 tarbals). Any suggestions on how to fix this in a clean way ? diff --git a/hw/xfree86/man/Makefile.am b/hw/xfree86/man/Makefile.am index f41d26c..5da404c 100644 --- a/hw/xfree86/man/Makefile.am +++ b/hw/xfree86/man/Makefile.am @@ -5,4 +5,6 @@ fileman_PRE = xorg.conf.man xorg.conf.d.man if SUID_WRAPPER appman_PRE += Xorg.wrap.man fileman_PRE += Xwrapper.config.man +else +EXTRA_DIST += Xorg.wrap.man Xwrapper.config.man endif In manpages.am: # The calling Makefile should only contain man page targets # Otherwise the following three global variables may conflict EXTRA_DIST = $(appman_PRE) $(driverman_PRE) $(fileman_PRE) CLEANFILES = $(appman_DATA) $(driverman_DATA) $(fileman_DATA) SUFFIXES = .$(APP_MAN_SUFFIX) .$(DRIVER_MAN_SUFFIX) .$(FILE_MAN_SUFFIX) .man We need to explicitly list files in EXTRA_DIST. We cannot use the built-in rules for man pages as they assume a hard-coded suffix (like .1 and so on). There is a problem in the content of the man page where the suffix is hard-coded. .TH Xorg.wrap 1 __xorgversion__ should be: .TH Xorg.wrap __appmansuffix__ __xorgversion__ as it is for Xorg.man Xwrapper.config goes in the file section (usually 5, but not always). It should be: .so man__appmansuffix__/Xwrapper.config.__appmansuffix__ We have a man page for a file that is pointing to a man page for an application. I am aware that section #1 is the same for all platforms, but it is the only one. All sections have been assigned a variable to have a common design which helps preventing other sections from being hard-coded. You can have a look at libXi for extensive use of .so man pages. Please double-check everything, it is error-prone. Regards, Hans ___ 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
Re: [PATCH 3/3] configure.ac: Remove check for WAYLAND_SCANNER_RULES
On 14-04-08 12:24 PM, Kristian Høgsberg wrote: This makes configure fail if the wayland autoconf macros aren't found. We don't need the scanner for shm-only xwayland so just drop this line for now. Signed-off-by: Kristian Høgsberg k...@bitplanet.net --- configure.ac | 1 - 1 file changed, 1 deletion(-) diff --git a/configure.ac b/configure.ac index 70eceab..cad4ceb 100644 --- a/configure.ac +++ b/configure.ac @@ -2458,7 +2458,6 @@ if test x$XWAYLAND = xyes; then XWAYLAND_SYS_LIBS=$XWAYLANDMODULES_LIBS $GLX_SYS_LIBS AC_SUBST([XWAYLAND_LIBS]) AC_SUBST([XWAYLAND_SYS_LIBS]) - WAYLAND_SCANNER_RULES(['$(top_srcdir)/hw/xwayland']) fi Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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: Xwayland DDX: build breaks in configuration
On 14-04-06 06:02 AM, Yaakov (Cygwin/X) wrote: Any idea how to fix this? I would prefer that the RC I'm still trying to construct will build for most people... Adding a copy of wayland-scanner.m4 to m4/ should work. This would work if this macro does not itself introduces more dependencies. The drawback is dual maintenance, as it must be updated when the original one is changed. In addition, a user could end up with both out-of-sync macros being on the search path, not really aware of which one will be picked-up. Another approach is to adopt the common idiom for auto detected features. If the macro is missing, for whatever reason, disable wayland building. It will require some m4 coding. Something like this: diff --git a/configure.ac b/configure.ac index 70eceab..b13f180 100644 --- a/configure.ac +++ b/configure.ac @@ -2442,6 +2442,8 @@ AM_CONDITIONAL(XFAKESERVER, [test x$KDRIVE = xyes test x$XFAKE = xyes]) dnl Xwayland DDX PKG_CHECK_MODULES(XWAYLANDMODULES, [wayland-client libdrm epoxy], [have_xwayland=yes], [have_xwayland=no]) +*m4_ifdef([WAYLAND_SCANNER_RULES]**, [have_xwayland=yes], [have_xwayland=no])* + AC_MSG_CHECKING([whether to build Xwayland DDX]) if test x$XWAYLAND = xauto; then XWAYLAND=$have_xwayland @@ -2458,7 +2460,8 @@ if test x$XWAYLAND = xyes; then XWAYLAND_SYS_LIBS=$XWAYLANDMODULES_LIBS $GLX_SYS_LIBS AC_SUBST([XWAYLAND_LIBS]) AC_SUBST([XWAYLAND_SYS_LIBS]) -WAYLAND_SCANNER_RULES(['$(top_srcdir)/hw/xwayland']) +*m4_ifdef([WAYLAND_SCANNER_RULES], WAYLAND_SCANNER_RULES(['$(top_srcdir)/hw/xwayland']))* + fi Not tested with xwayland installed, but no more build breaks without xwayland. Worth a try. ___ 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 xfs] Fix CFLAGS and LDFLAGS for Cygwin/MinGW
On 14-04-06 03:45 PM, Yaakov (Cygwin/X) wrote: +case $host_os in + cygwin*|mingw*) +CFLAGS=$CFLAGS -DFD_SETSIZE=256 +LDFLAGS=$LDFLAGS -Wl,--export-all ;; +esac We are not supposed to clobber user variables like CFLAGS. I didn't look at the particular cygwin environment, maybe it is already hopelessly clobbered, or there is no other way, but if not, it would be better not to start. The only time we have to do it is during a configuration test where we use save_CFLAGS=$CFLAGS and then restore it after the test. The goal is to allow the user to easily override the compiler flags established in the makefile, as the user has the final say in all this. This explains the role and the order of variables: http://www.gnu.org/software/automake/manual/automake.html#Flag-Variables-Ordering ___ 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 RESEND2 xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
Automake 1.14 gives us warning about source code specified in _SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. The test directory needs source from hw/xfree86 which is neither under test nor under a sub directory of test. In 1.14 we get a warning, in 2.0 it will break as it will overwrite the object code in xfree86. The solution in this case is to create a link to hw/xfree86/sdksyms.c at build time. It's just like any other built source file. There are no links created in git. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- test/.gitignore |1 + test/Makefile.am |8 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/test/.gitignore b/test/.gitignore index acbda7a..da86d6e 100644 --- a/test/.gitignore +++ b/test/.gitignore @@ -4,6 +4,7 @@ input list misc os +sdksyms.c string touch xfree86 diff --git a/test/Makefile.am b/test/Makefile.am index 2852bb3..afd8866 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -42,7 +42,7 @@ os_LDADD=$(TEST_LDADD) libxservertest_la_LIBADD = $(XSERVER_LIBS) if XORG -nodist_libxservertest_la_SOURCES = $(top_builddir)/hw/xfree86/sdksyms.c +nodist_libxservertest_la_SOURCES = sdksyms.c libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/loader/libloader.la \ $(top_builddir)/hw/xfree86/os-support/libxorgos.la \ @@ -56,6 +56,12 @@ libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/dixmods/libxorgxkb.la \ @XORG_LIBS@ +BUILT_SOURCES = sdksyms.c +CLEANFILES = sdksyms.c + +sdksyms.c: $(top_builddir)/hw/xfree86/sdksyms.c + $(AM_V_GEN)$(LN_S) $(top_builddir)/hw/xfree86/sdksyms.c + if DRI libxservertest_la_LIBADD += $(top_builddir)/hw/xfree86/dri/libdri.la endif -- 1.7.9.5 ___ 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 util-macros 1/2] Add XORG_AUTHORS macro to generate a list of authors from git
The macro generates a list of authors and creates the AUTHORS file in the module root directory. The AUTHORS_CMD is based on the ChangeLog command. A test for the git directory has been added so the 'git log' command is not invoked when we know that git is not reachable. The make targets for testing: make AUTHORS make dist make distcheck Testing should be done from both a git module and a tarball. The git shortlog command has been tried but it does not work when invoked inside the Makefile. Looking at several projects on the web, they all use the git log command. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in |1 + xorgversion.m4| 16 2 files changed, 17 insertions(+) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index f160a40..20b999e 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -1807,6 +1807,7 @@ XORG_STRICT_OPTION XORG_RELEASE_VERSION XORG_CHANGELOG XORG_INSTALL +XORG_AUTHORS XORG_MANPAGE_SECTIONS m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])], [AC_SUBST([AM_DEFAULT_VERBOSITY], [1])]) diff --git a/xorgversion.m4 b/xorgversion.m4 index 19f2ffd..6393100 100644 --- a/xorgversion.m4 +++ b/xorgversion.m4 @@ -62,3 +62,19 @@ mv \$(top_srcdir)/.changelog.tmp \$(top_srcdir)/ChangeLog) \ echo 'git directory not found: installing possibly empty changelog.' 2) AC_SUBST([CHANGELOG_CMD]) ]) # XORG_CHANGELOG + +# XORG_AUTHORS() +# -- +# Minimum version: 1.20.0 +# +# Defines the variable AUTHORS_CMD as the command to generate +# AUTHORS from git. +# +# +AC_DEFUN([XORG_AUTHORS], [ +AUTHORS_CMD=(GIT_DIR=\$(top_srcdir)/.git test -d \$(top_srcdir)/.git git log --format='%aN' | sort -u \$(top_srcdir)/.authors.tmp \ +mv \$(top_srcdir)/.authors.tmp \$(top_srcdir)/AUTHORS) \ +|| (rm -f \$(top_srcdir)/.authors.tmp; touch \$(top_srcdir)/AUTHORS; \ +echo 'git directory not found: installing possibly empty AUTHORS.' 2) +AC_SUBST([AUTHORS_CMD]) +]) # XORG_AUTHORS -- 1.7.9.5 ___ 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 util-macros 2/2] Use the new XORG_AUTHORS macro for the util-macros package
Signed-off-by: Gaetan Nadon mems...@videotron.ca --- .gitignore |1 + Makefile.am |9 +++-- configure.ac |1 + 3 files changed, 9 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 61198c9..058b4b5 100644 --- a/.gitignore +++ b/.gitignore @@ -5,6 +5,7 @@ # Do not edit the following section # GNU Build System (Autotools) aclocal.m4 +AUTHORS autom4te.cache/ autoscan.log ChangeLog diff --git a/Makefile.am b/Makefile.am index 134a5cc..e9d95e8 100644 --- a/Makefile.am +++ b/Makefile.am @@ -32,9 +32,14 @@ install-data-hook: pkgconfigdir = $(datadir)/pkgconfig pkgconfig_DATA = xorg-macros.pc -.PHONY: ChangeLog +MAINTAINERCLEANFILES = ChangeLog AUTHORS + +.PHONY: ChangeLog AUTHORS ChangeLog: $(CHANGELOG_CMD) -dist-hook: ChangeLog +AUTHORS: + $(AUTHORS_CMD) + +dist-hook: ChangeLog AUTHORS diff --git a/configure.ac b/configure.ac index e38e004..7c9cc28 100644 --- a/configure.ac +++ b/configure.ac @@ -38,6 +38,7 @@ m4_include([xorgversion.m4]) XORG_RELEASE_VERSION XORG_CHANGELOG +XORG_AUTHORS AC_CONFIG_FILES([xorg-macros.pc Makefile xorg-macros.m4:xorg-macros.m4.in:xorgversion.m4]) -- 1.7.9.5 ___ 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
Xwayland DDX: build breaks in configuration
http://tinderbox.x.org/builds/2014-04-03-0020/logs/xserver/#configure
checking whether to build Xwayland DDX... no
/home/robclark/xorg/xserver/configure: line 31420: syntax error near unexpected
token `'$(top_srcdir)/hw/xwayland''
/home/robclark/xorg/xserver/configure: line 31420: `
WAYLAND_SCANNER_RULES('$(top_srcdir)/hw/xwayland')'
___
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 xinit v3 1/3] Bump required util-macros version to 1.19
On 14-03-31 09:51 AM, Hans de Goede wrote: Signed-off-by: Hans de Goede hdego...@redhat.com --- configure.ac | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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 xinit v3 2/3] Drop Replace $RAWCPPFLAGS with $TRADITIONALCPPFLAGS when processing cpp files
On 14-03-31 09:51 AM, Hans de Goede wrote: Various .cpp files containt things like #ifdef __APPLE__ and #ifdef __linux__ these have been broken (all #ifdef-s always seen as false) since: http://cgit.freedesktop.org/xorg/util/macros/commit/?id=d690e4a9febd07988d149a967791c5629c17b258 This commit makes these work again. Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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: Not able to cross-compile xserver
On 14-04-01 04:45 AM, Prashant Bhumkar wrote: configure: WARNING: unrecognized options: --with-driver, --with-mesa-source, --enable-malloc0returnsnull Regarding --enable-malloc0returnsnull, see: http://cgit.freedesktop.org/xorg/util/macros/commit/?id=72fdc868b56fe2b7bdc9a69872651baeca728fb6 The wiki has not been updated. The method being promoted is to seed the appropriate value in the cache file. I don't do cross compiling myself so I cannot explain it very well. Feel free to correct the wiki or post the changes here, I'll do the update. http://lists.freedesktop.org/archives/xorg/2008-December/041719.html http://lists.freedesktop.org/archives/mesa-commit/2012-January/034948.html ___ 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
[ANNOUNCE] util-macros 1.19.0
Alan Coopersmith (1): XORG_COMPILER_FLAGS: Add -Wlogical-op to default warning set Arnaud Fontaine (1): Add XORG_WITH_M4 macro Gaetan Nadon (3): Bump minimum Autoconf required version to 2.62 Provide the automake INSTALL file at level 1.11 Version bump: 1.19.0 Hans de Goede (1): XORG_PROG_RAWCPP: Add TRADITIONALCPPFLAGS git tag: util-macros-1.19.0 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.19.0.tar.bz2 MD5: 1cf984125e75f8204938d998a8b6c1e1 util-macros-1.19.0.tar.bz2 SHA1: 00cfc636694000112924198e6b9e4d72f1601338 util-macros-1.19.0.tar.bz2 SHA256: 2835b11829ee634e19fa56517b4cfc52ef39acea0cd82e15f68096e27cbed0ba util-macros-1.19.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.19.0.tar.gz MD5: 40e1caa49a71a26e0aa68ddd00203717 util-macros-1.19.0.tar.gz SHA1: ac9cb34a6b9919ad197ddd12ead74b634d7d2147 util-macros-1.19.0.tar.gz SHA256: 0d4df51b29023daf2f63aebf3ebc638ea88efedfd560ab5866741ab3f92acaa1 util-macros-1.19.0.tar.gz ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[ANNOUNCE] util-macros 1.19.0
Alan Coopersmith (1): XORG_COMPILER_FLAGS: Add -Wlogical-op to default warning set Arnaud Fontaine (1): Add XORG_WITH_M4 macro Gaetan Nadon (3): Bump minimum Autoconf required version to 2.62 Provide the automake INSTALL file at level 1.11 Version bump: 1.19.0 Hans de Goede (1): XORG_PROG_RAWCPP: Add TRADITIONALCPPFLAGS git tag: util-macros-1.19.0 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.19.0.tar.bz2 MD5: 1cf984125e75f8204938d998a8b6c1e1 util-macros-1.19.0.tar.bz2 SHA1: 00cfc636694000112924198e6b9e4d72f1601338 util-macros-1.19.0.tar.bz2 SHA256: 2835b11829ee634e19fa56517b4cfc52ef39acea0cd82e15f68096e27cbed0ba util-macros-1.19.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.19.0.tar.gz MD5: 40e1caa49a71a26e0aa68ddd00203717 util-macros-1.19.0.tar.gz SHA1: ac9cb34a6b9919ad197ddd12ead74b634d7d2147 util-macros-1.19.0.tar.gz SHA256: 0d4df51b29023daf2f63aebf3ebc638ea88efedfd560ab5866741ab3f92acaa1 util-macros-1.19.0.tar.gz ___ xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
Re: [PATCH util/macros] XORG_PROG_RAWCPP: Add TRADITIONALCPPFLAGS
On 14-03-27 07:56 AM, Hans de Goede wrote: In some cases we may want to have -traditional for proper whitespace preserving without -undef, as we actually want the system definitions to be in place so we can #ifdef on them. IE in xinit various .cpp files contain things like #ifdef __APPLE__ and #ifdef __linux__ So this patch adds a TRADITIONALCPPFLAGS variable which contains just -traditional where applicable without the other RAWCPPFLAGS for unsetting the system definitions. This preserves backwards compatibility. Once pushed, I need to make a new release for util-macros @ version 1.19. Any module using TRADITIONALCPPFLAGS will need to require version 1.19. Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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 xinit v2 1/3] Remove unixware / sco support
On 14-03-27 07:55 AM, Hans de Goede wrote: We don't support SCO / Unixware anymore, so lets remove the SCO / Unixware specific bits from startx and xinitrc Signed-off-by: Hans de Goede hdego...@redhat.com Reviewed-by: Gaetan Nadon mems...@videotron.ca SCO support was removed from the server in 2010: http://lists.x.org/archives/xorg-devel/2010-December/017209.html ___ 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 util/macros] XORG_PROG_RAWCPP: Add TRADITIONALCPPFLAGS
On 14-03-27 08:48 AM, Hans de Goede wrote: Once the 1.19 release is done I'll write a patch for xinit to bump the required util-macros version (and out that in my patchset before the patch using the new TRADITIONALCPPFLAGS. Release 1.19 is out. http://xorg.freedesktop.org/archive/individual/util/ # Require X.Org macros 1.19 or later for TRADITIONALCPPFLAGS in XORG_PROG_RAWCPP m4_ifndef([XORG_MACROS_VERSION], [m4_fatal([must install xorg-macros 1.19 or later before running autoconf/autogen])]) XORG_MACROS_VERSION(1.19) ___ 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 xinit 1/3] Drop $RAWCPPFLAGS when generating startx
On 14-03-26 07:37 AM, Hans de Goede wrote: Hi, On 03/25/2014 06:22 PM, Gaetan Nadon wrote: On 14-03-25 07:56 AM, Hans de Goede wrote: startx.cpp contains things like #if defined(__SCO__), and $RAWCPPFLAGS contains -undef causing these to not get set. Signed-off-by: Hans de Goede hdego...@redhat.com --- cpprules.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/cpprules.in b/cpprules.in index 0931bee..781676a 100644 --- a/cpprules.in +++ b/cpprules.in @@ -15,4 +15,4 @@ CPP_SED_MAGIC = $(SED) -e '/^\# *[0-9][0-9]* *.*$$/d' \ SUFFIXES = .cpp .cpp: - $(AM_V_GEN)$(RAWCPP) $(RAWCPPFLAGS) $(CPP_FILES_FLAGS) $ | $(CPP_SED_MAGIC) $@ + $(AM_V_GEN)$(RAWCPP) $(CPP_FILES_FLAGS) $ | $(CPP_SED_MAGIC) $@ 1. It looks like it has been this way for a very long time. Have you investigated why it isn't a problem today? I've not investigated, but I assume it is not a problem today since most of the #ifdef-s are for platforms which are not being used much (if at all) anymore. Note my main reasons for fixing this are: 1) If we've #ifdef's on platform specific defines in there, they should work, otherwise we should just rip them out. Yes. 2) The second patch in this patchset introduces a #ifdef __linux__ which won't work with the -undef. I see the problem. 2. This is going to change the xinitrc for Apple. How confident are you that the patch will not create a problem? I found on the net (http://arstechnica.com/civis/viewtopic.php?f=19t=371721) a user posting his copy of xinitrc for Apple. if [ -f $sysresources ]; then xrdb -merge $sysresources fi When removing -undef, my guess is that the command will be XRDB -nocpp -merge $sysresources. Right or wrong, I don't know. Unless apple users have custom Xresources using #ifdef's or some such this should not matter, so I believe this won't cause any issues. If we're worried about this causing issues we could start with a patch removing all the existing #ifdef blocks, since they have been dead code for a while anyways. That would be prudent. Those who have specific platform skills could review. It also leaves a better trace in git as to what and why things have been done. 3. As for SCO, this OS is no longer supported, so we will never know. Right, as said we should consider ripping out all the existing #ifdef's first. Take a look at app/xdm/config/Xsession.cpp. 4. Aside from undef, there is the option traditional that the patch also throws away. It has to do with the treatment of whitespace. Right, it introduces a lot of extra newlines, dropping this actually makes the generated startx script nicer to read as there are no more unnecessary large whitespace blocks Any idea on what happens to other platforms and/or other non-gnu compilers? No, I assume that other the some newlines disappearing there as well there will be no impact, but only testing will tell for sure. The -undef flag was added in Sept 2005. Are you running into a problem? The problem is I cannot use #ifdef for the 2nd patch in this set without fixing the -undef problem. Ok. There is a mystery to be resolved... http://cgit.freedesktop.org/xorg/util/macros/commit/?id=d690e4a9febd07988d149a967791c5629c17b258 If these defines have always been useless, a bigger cleanup could be done. Agreed on the bigger cleanup, I guess I could do that first as a preparation patch. Then effectively the only change the dropping of RAWCPPFLAGS will cause is the dropping of the traditional option. Ok, it makes sense. Let's fix the cpp source first. The content of RAWCPPFLAGS vary by platform and compiler, so it is difficult to review. Regards, Hans ___ 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 xserver] suid: adding Xorg.sh.in to EXTRA_DIST is redundant
All files specified in AC_CONFIG_FILES get distributed automatically. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- hw/xfree86/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am index 18fa99b..ceb4c6a 100644 --- a/hw/xfree86/Makefile.am +++ b/hw/xfree86/Makefile.am @@ -89,7 +89,7 @@ endif BUILT_SOURCES = xorg.conf.example DISTCLEANFILES = xorg.conf.example -EXTRA_DIST = xorgconf.cpp Xorg.sh.in +EXTRA_DIST = xorgconf.cpp # Without logdir, X will post an error on the terminal and will not start install-data-local: -- 1.7.9.5 ___ 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 xorg-docs] Fix typo in Release Notes.
Signed-off-by: Gaetan Nadon mems...@videotron.ca --- general/ReleaseNotes.xml |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/general/ReleaseNotes.xml b/general/ReleaseNotes.xml index 8fd43ba..72fb644 100644 --- a/general/ReleaseNotes.xml +++ b/general/ReleaseNotes.xml @@ -270,7 +270,7 @@ The next section describes what is new in the latest version dynamically load the video drivers, input drivers, and other modules that are needed. - commandXorg/command has currently has support for Linux, Solaris, + commandXorg/command currently has support for Linux, Solaris, and some BSD OSs on Alpha, PowerPC, IA-64, AMD64, Intel x86, Sparc, and MIPS platforms. -- 1.7.9.5 ___ 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: Problems while compiling xorg on Ubuntu
Fedora patches it too, see the end of: http://pkgs.fedoraproject.org/cgit/xorg-x11-drv-sis.git/tree/sis-0.10.7-git.patch |+miPointerSetPosition(inputInfo.pointer, Absolute, dx, dy, NULL, NULL);| This patch gets rid of the compile error but does not work. A real event list and count must be passed in as Peter Hutterer explained: not quite, sorry. nevents is an return value, we pass this down because miPointerSetPosition may actually add events to the list. this must be an actual event list, the code here would likely segfault if there are barriers (see input_constrain_cursor). ___ 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 xserver] xfree86: glamor_egl subdir must be distributed - breaks distcheck
On 14-03-21 04:53 PM, Eric Anholt wrote: Gaetan Nadon mems...@videotron.ca writes: Signed-off-by: Gaetan Nadon mems...@videotron.ca I've reviewed these two patches of yours and they'll be in my next pull request. Thanks! Great, thanks. ___ 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: Problems while compiling xorg on Ubuntu
On 14-03-21 04:20 PM, pplive wrote: I try to compile xorg according to the following instruction: http://www.x.org/wiki/Building_the_X_Window_System/ When I tried to execute ./util/modular/build.sh --clone $HOME/build, I have received the following error information: The sis driver has been unmaintained for a long time. The build.sh contains pretty much all of the video drivers one may need. There are about 50 of them. Most would work only with a specific video card anyway. Feel free to trim the list of modules you reasonably need. Use build.sh -L to create a list of modules in a file. Trim it, and run build.sh with --modfile. --modfile modulefile Only process the module/components specified in modulefile Any text after, and on the same line as, the module/component is assumed to be configuration options for the configuration of each module/component specifically You can compare your build output with others that are posted on http://tinderbox.x.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: Problems while compiling xorg on Ubuntu
On 14-03-22 06:06 PM, Felix Miata wrote: On 2014-03-22 16:58 (GMT-0400) Gaetan Nadon composed: The sis driver has been unmaintained for a long time. The build.sh contains pretty much all of the video drivers one may need. There are about 50 of them. Most would work only with a specific video card anyway. Feel free to trim the list of modules you reasonably need. To be sure, it is not broken for everyone. I have it working here with openSUSE X Server 1.15.0 and Z7/XG20 gfxchip. Interesting, how does it not hit this error? sis_driver.c: In function 'SISMergedPointerMoved': sis_driver.c:9384:13: error: too few arguments to function 'miPointerSetPosition' This was introduced with a server code change 21a15f9a04ec0a6c8f654eef943561e98db2475d. ABI level 1.19. A couple of parameters was added to the function ScreenPtr miPointerSetPosition(DeviceIntPtr pDev, int mode, double *screenx, - double *screeny) + double *screeny, + int *nevents, InternalEvent* events) ___ 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 3/2] Build fbcmap_mi.c once, rather than for each DDX
On 14-03-22 03:27 PM, Jon TURNEY wrote: On 19/03/2014 21:29, Gaetan Nadon wrote: On 14-03-03 10:08 AM, Jon TURNEY wrote: Build fbcmap_mi.c once, rather than for each DDX, and make it part of libfb or libwfb convenience library. Since 84e8de1271bb11b5b4b9747ae4647f47333a8ab7 we don't have fbcmap.c This is a sort of revert of 7ecc2d526c4ea5db2589644a2fec0daf71df36da kdrive fbdev fails because libkdrivestubs is added in configure.ac. Consider this change: diff --git a/configure.ac b/configure.ac index 162c0cf..d7a55a4 100644 --- a/configure.ac +++ b/configure.ac @@ -2400,8 +2400,7 @@ if test $KDRIVE = yes; then fi ;; esac -KDRIVE_STUB_LIB='$(top_builddir)/hw/kdrive/src/libkdrivestubs.la' -KDRIVE_LOCAL_LIBS=$MAIN_LIB $DIX_LIB $KDRIVE_LIB $KDRIVE_STUB_LIB +KDRIVE_LOCAL_LIBS=$MAIN_LIB $DIX_LIB $KDRIVE_LIB KDRIVE_LOCAL_LIBS=$KDRIVE_LOCAL_LIBS $FB_LIB $MI_LIB $KDRIVE_PURE_LIBS KDRIVE_LOCAL_LIBS=$KDRIVE_LOCAL_LIBS $KDRIVE_OS_LIB KDRIVE_LIBS=$KDRIVE_LOCAL_LIBS $XSERVER_SYS_LIBS $GLX_SYS_LIBS $DLOPEN_LIB Thanks. Squashed this into revised patch attached. It looks like Xnest does not need libfb at all which is set in configure.ac. It does not cause any problem, however. I guess that makes some kind of sense. Reviewed-by: Gaetan Nadon mems...@videotron.ca Feel free to review/scoop [PATCH RESEND xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time It's also to fix the subdir-objects issue in future automake versions. ___ 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] .gitignore: Add new autotools file 'test-driver'
On 14-03-19 01:12 AM, Kristian Høgsberg wrote: Recent automake introduces a new shell script helper for the automake test framework. Add it to .gitignore. Signed-off-by: Kristian Høgsberg k...@bitplanet.net --- Gaetan, not sure what the convention is for .gitignore. You added the Do not edit comment, but I don't see any other mechanism for updating the autotools list. That's the right place for doing it. Can you specify which level of automake in the commit text? Will all modules need this? Or just those including some specific autoconf macros? I'll make a note to add this one for the next revision of .gitignore. Kristian .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 94a12fd..dc56b46 100644 --- a/.gitignore +++ b/.gitignore @@ -41,6 +41,7 @@ mkinstalldirs py-compile stamp-h? symlink-tree +test-driver texinfo.tex ylwrap ___ 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] .gitignore: Add new autotools file 'test-driver'
On 14-03-19 07:44 AM, Gaetan Nadon wrote: Can you specify which level of automake in the commit text? Will all modules need this? Or just those including some specific autoconf macros? It was introduced in automake 1.12 with the changes in the test suite framework. It would be best to write it as: /test-driver in case there would be an executable name somewhere down in subdirs. Also you should add *.log and *.trs in the test/.gitignore file as those files need to be ignored as well. It would be tempting to ignore the pattern from the root directory, but you never know, there could be a legitimate .log or .trs file somewhere, someday. ___ 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 xserver] ephyr: spurious $() in the Makefile breaks the make 'dist' target
Introduced in commit 9fe052d90cca90fdf750d3a45b151be2ac7f0ebd Signed-off-by: Gaetan Nadon mems...@videotron.ca --- hw/kdrive/ephyr/Makefile.am | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/hw/kdrive/ephyr/Makefile.am b/hw/kdrive/ephyr/Makefile.am index 040993c..55320eb 100644 --- a/hw/kdrive/ephyr/Makefile.am +++ b/hw/kdrive/ephyr/Makefile.am @@ -37,8 +37,7 @@ endif if GLAMOR GLAMOR_SRCS = \ ephyr_glamor_glx.c \ - ephyr_glamor_glx.h \ - () + ephyr_glamor_glx.h endif if DRI @@ -50,8 +49,7 @@ DRI_SRCS =\ ephyrglxext.c \ ephyrglxext.h \ ephyrhostglx.c \ - ephyrhostglx.h \ - $() + ephyrhostglx.h endif bin_PROGRAMS = Xephyr @@ -67,15 +65,13 @@ Xephyr_SOURCES = \ hostx.h \ $(XV_SRCS) \ $(DRI_SRCS) \ - $(GLAMOR_SRCS) \ - $() + $(GLAMOR_SRCS) if GLAMOR AM_CPPFLAGS += $(XLIB_CFLAGS) XEPHYR_GLAMOR_LIB = \ $(top_builddir)/glamor/libglamor.la \ - $(top_builddir)/glamor/libglamor_egl_stubs.la \ - $() + $(top_builddir)/glamor/libglamor_egl_stubs.la endif Xephyr_LDADD = \ -- 1.7.9.5 ___ 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 xserver] xfree86: glamor_egl subdir must be distributed - breaks distcheck
Signed-off-by: Gaetan Nadon mems...@videotron.ca --- hw/xfree86/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xfree86/Makefile.am b/hw/xfree86/Makefile.am index 73e1b4c..c4aa177 100644 --- a/hw/xfree86/Makefile.am +++ b/hw/xfree86/Makefile.am @@ -43,7 +43,7 @@ SUBDIRS = common ddc x86emu $(INT10_SUBDIR) os-support parser \ DIST_SUBDIRS = common ddc i2c x86emu int10 fbdevhw os-support \ parser ramdac shadowfb vbe vgahw \ loader dixmods dri dri2 exa modes \ - utils doc man + utils doc man glamor_egl bin_PROGRAMS = Xorg nodist_Xorg_SOURCES = sdksyms.c -- 1.7.9.5 ___ 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 1/2] .gitignore: Add new autotools file 'test-driver'
On 14-03-19 01:27 PM, Kristian Høgsberg wrote: Automake 1.12 introduces a new parallel test framework that uses a shell script helper and generates *.log and *.trs files. Add to .gitignore. Signed-off-by: Kristian Høgsberg k...@bitplanet.net Cc: Gaetan Nadon mems...@videotron.ca --- .gitignore | 1 + test/.gitignore | 2 ++ 2 files changed, 3 insertions(+) diff --git a/.gitignore b/.gitignore index 94a12fd..dc56b46 100644 --- a/.gitignore +++ b/.gitignore @@ -41,6 +41,7 @@ mkinstalldirs py-compile stamp-h? symlink-tree +test-driver texinfo.tex ylwrap diff --git a/test/.gitignore b/test/.gitignore index acbda7a..f8653e3 100644 --- a/test/.gitignore +++ b/test/.gitignore @@ -10,3 +10,5 @@ xfree86 xkb xtest signal-logging +*.log +*.trs Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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] .gitignore: Add new autotools file 'test-driver'
On 14-03-19 12:42 PM, Guillem Jover wrote: Actually, why are those in the root dir, and not confined under something like AC_CONFIG_AUX_DIR([build-aux])? A handful of modules do that and is perfectly ok. A while ago I had considered doing just to all xorg modules. The vast majority of 250 xorg modules are small, so the content of build-aux is rather small and there were still many files left in the root. Not much bang for the buck. Many (if not all) drivers and tests specify AC_CONFIG_AUX_DIR(.) which kind of defeats the point of the macro, and I never changed it on the driver I maintain because I suspected there might be a rationale for that? So if there is, it would be nice to know. :) I don't think there was. The drivers autotools files were created via scripting which explains why they are similar. No one changed it for the same reason you didn't. That was done before my time, when automake 1.7 was used. Who knows what bugs/workarounds were needed at the time! It could be removed today, but some could object the majority of drivers are obsolete and should be left alone. ___ 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 xserver] ephyr: spurious $() in the Makefile breaks the make 'dist' target
On 14-03-19 12:51 PM, Guillem Jover wrote: One reason to use something (in spirit) like this is to avoid unnecessary line changes whenever a new entry is appended to the list, which might also generate less conflicts. I tend to use $(nil) as the last item in those cases. The other option is to switch the assignment to “=+”, but that seems more verbose. Now that you mention it, I recall seeing this somewhere. I went back and there was only one offending construct: if GLAMOR GLAMOR_SRCS = \ ephyr_glamor_glx.c \ ephyr_glamor_glx.h \ () endif Producing: make[3]: Entering directory `/home/nadon/xorg/src/xserver/hw/kdrive/ephyr' make[3]: *** No rule to make target `()', needed by `distdir'. Stop. make[3]: Leaving directory `/home/nadon/xorg/src/xserver/hw/kdrive/ephyr' make[2]: *** [distdir] Error 1 It's a typo where () was written instead of $(). I wrongly assumed they were all bad, typos or not! I'll write another patch. ___ 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 xserver] ephyr: typo where () should be $() in the Makefile - breaks make dist
make[3]: Entering directory `/home/nadon/xorg/src/xserver/hw/kdrive/ephyr' make[3]: *** No rule to make target `()', needed by `distdir'. Stop. make[3]: Leaving directory `/home/nadon/xorg/src/xserver/hw/kdrive/ephyr' make[2]: *** [distdir] Error 1 Signed-off-by: Gaetan Nadon mems...@videotron.ca --- hw/kdrive/ephyr/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/kdrive/ephyr/Makefile.am b/hw/kdrive/ephyr/Makefile.am index 040993c..00a53d0 100644 --- a/hw/kdrive/ephyr/Makefile.am +++ b/hw/kdrive/ephyr/Makefile.am @@ -38,7 +38,7 @@ if GLAMOR GLAMOR_SRCS = \ ephyr_glamor_glx.c \ ephyr_glamor_glx.h \ - () + $() endif if DRI -- 1.7.9.5 ___ 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 3/2] Build fbcmap_mi.c once, rather than for each DDX
On 14-03-03 10:08 AM, Jon TURNEY wrote: Build fbcmap_mi.c once, rather than for each DDX, and make it part of libfb or libwfb convenience library. Since 84e8de1271bb11b5b4b9747ae4647f47333a8ab7 we don't have fbcmap.c This is a sort of revert of 7ecc2d526c4ea5db2589644a2fec0daf71df36da kdrive fbdev fails because libkdrivestubs is added in configure.ac. Consider this change: diff --git a/configure.ac b/configure.ac index 162c0cf..d7a55a4 100644 --- a/configure.ac +++ b/configure.ac @@ -2400,8 +2400,7 @@ if test $KDRIVE = yes; then fi ;; esac -KDRIVE_STUB_LIB='$(top_builddir)/hw/kdrive/src/libkdrivestubs.la' -KDRIVE_LOCAL_LIBS=$MAIN_LIB $DIX_LIB $KDRIVE_LIB $KDRIVE_STUB_LIB +KDRIVE_LOCAL_LIBS=$MAIN_LIB $DIX_LIB $KDRIVE_LIB KDRIVE_LOCAL_LIBS=$KDRIVE_LOCAL_LIBS $FB_LIB $MI_LIB $KDRIVE_PURE_LIBS KDRIVE_LOCAL_LIBS=$KDRIVE_LOCAL_LIBS $KDRIVE_OS_LIB KDRIVE_LIBS=$KDRIVE_LOCAL_LIBS $XSERVER_SYS_LIBS $GLX_SYS_LIBS $DLOPEN_LIB I used these configure options: --enable-dmx --enable-kdrive --enable-xfake --enable-xfbdev --enable-xnest --enable-glamor Note that kdrive ephyr fails to compile without glamor enabled. XNEST_LIBS=$FB_LIB ... It looks like Xnest does not need libfb at all which is set in configure.ac. It does not cause any problem, however. Thanks for the patch! ___ 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 RESEND2 xserver] Default font path: remove the check for ${sysconfdir}/X11/fontpath.d
On 14-02-08 09:28 AM, Gaetan Nadon wrote: I'd like to get some review from people familiar with the distro packaging process to understand if this analysis is accurate; I haven't any way to know what the effect of this change would be otherwise. I would like to as well. The dead code is trying to implement a feature, so we can remove the dead code, or try to fix it. My investigation lead me to believe that the feature is not implementable, so the patch just removes the dead code. If we don't hear from anyone regarding a proper implementation of the feature, I suggest applying the patch. Given it is dead code and has never worked since inception 4 years ago, the risk is zero. The time for a conclusion has come... ___ 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 RESEND xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
Automake 1.14 gives us warning about source code specified in _SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. The test directory needs source from hw/xfree86 which is neither under test nor under a sub directory of test. In 1.14 we get a warning, in 2.0 it will break as it will overwrite the object code in xfree86. The solution in this case is to create a link to hw/xfree86/sdksyms.c at build time. It's just like any other built source file. There are no links created in git. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- test/.gitignore |1 + test/Makefile.am |8 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/test/.gitignore b/test/.gitignore index acbda7a..da86d6e 100644 --- a/test/.gitignore +++ b/test/.gitignore @@ -4,6 +4,7 @@ input list misc os +sdksyms.c string touch xfree86 diff --git a/test/Makefile.am b/test/Makefile.am index 2852bb3..afd8866 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -42,7 +42,7 @@ os_LDADD=$(TEST_LDADD) libxservertest_la_LIBADD = $(XSERVER_LIBS) if XORG -nodist_libxservertest_la_SOURCES = $(top_builddir)/hw/xfree86/sdksyms.c +nodist_libxservertest_la_SOURCES = sdksyms.c libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/loader/libloader.la \ $(top_builddir)/hw/xfree86/os-support/libxorgos.la \ @@ -56,6 +56,12 @@ libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/dixmods/libxorgxkb.la \ @XORG_LIBS@ +BUILT_SOURCES = sdksyms.c +CLEANFILES = sdksyms.c + +sdksyms.c: $(top_builddir)/hw/xfree86/sdksyms.c + $(AM_V_GEN)$(LN_S) $(top_builddir)/hw/xfree86/sdksyms.c + if DRI libxservertest_la_LIBADD += $(top_builddir)/hw/xfree86/dri/libdri.la endif -- 1.7.9.5 ___ 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:mkfontscale 1/2] Only include config.h if it exists.
On 14-03-18 06:18 PM, Thomas Klausner wrote: Signed-off-by: Thomas Klausner w...@netbsd.org --- hash.c| 2 ++ mkfontscale.c | 2 ++ 2 files changed, 4 insertions(+) Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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 util/modular] jhbuildrc: Restore mesa-demos, mesa-glut, mesa-glu
On 14-03-18 12:56 PM, Jon TURNEY wrote: On 16/03/2014 18:15, Gaetan Nadon wrote: On 14-03-15 02:17 PM, Jon TURNEY wrote: On 14/03/2014 20:03, Jon TURNEY wrote: As of 9167c5e7177a758fce55afe759fa48c47a4f7f4e we had mesa-demos, mesa-glut and mesa-glu modules. 9167c5e7177a758fce55afe759fa48c47a4f7f4e add missing modules and meta modules (confusingly) removes them. Restore mesa-demos, mesa-glut, mesa-glu so they get tinderboxed. Sorry, that was completely the wrong patch. Try the attached, instead. The reason I had not included these is that they are not needed to build a runnable X Window System, to my knowledge (I could be wrong on that). Okay. But xorg.modules contains lots of stuff which isn't required for that (e.g. app-xman), and if it's going to drive tinderbox, it should, I think, build as much stuff as we can stand, so that commits which break something have more chance to be noticed as soon as possible. I know, there is no logic to describe what should or should not be in tinderbox. It's more or less based on consensus. If you do need those, go ahead, no objections. So as long it is not just because they were there before. It would be nice to describe in the commit text the reason why we add/remove modules from jhbuild or build.sh. Thanks! I noticed the patch was reverted. With my usual bumbling incompetence, I typed 'git push' into the wrong terminal and pushed the unreviewed, broken version of this patch, so I also pushed a revert. As for fontconfig, I always hesitated. It has been available on all platforms for the longest time, I never understood why it was included. And we don't need the latest unreleased version. This is a separate issue, but again, unless it is tinderboxed elsewhere, I wouldn't want to see it removed. ___ 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 util/modular] jhbuildrc: Restore mesa-demos, mesa-glut, mesa-glu
On 14-03-15 02:17 PM, Jon TURNEY wrote: On 14/03/2014 20:03, Jon TURNEY wrote: As of 9167c5e7177a758fce55afe759fa48c47a4f7f4e we had mesa-demos, mesa-glut and mesa-glu modules. 9167c5e7177a758fce55afe759fa48c47a4f7f4e add missing modules and meta modules (confusingly) removes them. Restore mesa-demos, mesa-glut, mesa-glu so they get tinderboxed. Sorry, that was completely the wrong patch. Try the attached, instead. The reason I had not included these is that they are not needed to build a runnable X Window System, to my knowledge (I could be wrong on that). I noticed the patch was reverted. As for fontconfig, I always hesitated. It has been available on all platforms for the longest time, I never understood why it was included. And we don't need the latest unreleased version. ___ 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 libxtrans] configure: under glibc define _GNU_SOURCE rather then _BSD_SOURCE
On 14-03-08 09:03 AM, Hans de Goede wrote: So I've just been looking into using AC_USE_SYSTEM_EXTENSIONS but that seem pretty useless, it only adds the relevant defines to confdefs.h, not into cflags, and in libxtrans we want to add them to the .pc file, so we need them in a variable. I'm open to different suggestions, but I think my initial patch might be the best way to fix this. Check the pattern in other modules such as libX11. The source code includes the content of the generated config.h (see config.h.in). #ifdef HAVE_CONFIG_H #include config.h #endif which contains definitions such as: /* Enable GNU extensions on systems that have them. */ #ifndef _GNU_SOURCE # define _GNU_SOURCE 1 #endif /* Enable threading extensions on Solaris. */ #ifndef _POSIX_PTHREAD_SEMANTICS # define _POSIX_PTHREAD_SEMANTICS 1 #endif /* Enable extensions on HP NonStop. */ #ifndef _TANDEM_SOURCE # define _TANDEM_SOURCE 1 #endif /* Enable general extensions on Solaris. */ #ifndef __EXTENSIONS__ # define __EXTENSIONS__ 1 #endif and so on... When a module is configured (running ./configure), the appropriate values are filled-in based on what the platform is. If hard coded in the C code, all this work has to be done all over again. In addition, this mechanism was put in place because the gcc command might be lengthy on some platforms. Check it out, it should solve the problem. ___ 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: Compiling xf86-video-xgi driver for ARM
On 14-02-27 04:47 AM, Artem Makarov wrote: Too bad. XGIFB is very slow, I wanted to get at least some acceleration with xorg driver. Indeed. This is an open source project, if anyone is willing to contribute... http://www.x.org/wiki/Development/Documentation/SubmittingPatches/ ___ 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: Compiling xf86-video-xgi driver for ARM
On 14-02-26 07:48 AM, Artemy Makarov wrote: I have a ARM PC, similar to hp t5325, based on Marvell CPU and XGI Volari z11 video chip. I've compiled xf86-video-xgi driver for it, but it doesn't work. FYI, this driver was removed from the regular build in Dec 2011. xorg.modules: Remove xf86-video-xgi This hasn't been usable for multiple years and obviously nobody cares about fixing it, so remove it from the default set, so the tinderbox stops reporting it as a failure. ___ 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 xfs 1/3] Warning fixes.
On 14-01-29 04:14 PM, Keith Packard wrote: This patch also stops re-using the 'port' variable in GetInetdListenInfo when fetching the ReopenInfo. That's not strictly necessary here, but will be useful when the Reopen API in libxtrans changes to take a constant parameter. Signed-off-by: Keith Packard kei...@keithp.com Pushed to fix the broken build. To ssh://git.freedesktop.org/git/xorg/app/xfs b7cd80d..2c79452 master - master ___ 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 xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
On 14-02-23 11:46 PM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: Automake 1.14 gives us warning about source code specified in _SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. Can we turn on the subdir-objects feature after this patch then? Not yet. And it would be only for this Makefile.am, not for the whole server code. There are those three other cases to handle: nodist_libxservertest_la_SOURCES = \ ddxstubs.c \ $(top_srcdir)/mi/miinitext.c \ $(top_srcdir)/Xext/dpmsstubs.c \ $(top_srcdir)/Xi/stubs.c Jon Turney just posted a patches Build Xi and DPMS stubs as convenience libraries which takes care of two out of the three cases (If I understand correctly, just done a quick read). That would leave miinitext.c to handle. Note that we do not need the subdir-objects feature, but automake 2.0 will turn it on any (and it cannot be turned off). We happen to have code that will trip this feature. So we need to fix it before 2.0 gets pervasive. This is the complete list of Makefile.am affected by this issue. Xi/Makefile.am fb/Makefile.am hw/dmx/Makefile.am hw/dmx/config/Makefile.am hw/kdrive/src/Makefile.am hw/vfb/Makefile.am hw/xfree86/dixmods/Makefile.am hw/xfree86/int10/Makefile.am hw/xfree86/os-support/bsd/Makefile.am hw/xfree86/os-support/hurd/Makefile.am hw/xfree86/os-support/linux/Makefile.am hw/xfree86/os-support/solaris/Makefile.am hw/xfree86/os-support/stub/Makefile.am hw/xfree86/parser/Makefile.am hw/xfree86/utils/cvt/Makefile.am hw/xnest/Makefile.am hw/xquartz/Makefile.am hw/xquartz/mach-startup/Makefile.am hw/xwin/Makefile.am test/Makefile.am The other area that has not been tackled yet is in the os-support and the shared directory: Mark Kettenis has commented: Note that not all warnings are actually problems. For example the directories under hw/xfree86/os-support are largely subdir-objects safe. Probably enough to make sure hw/xfree86/os-support/shared gets created in the build directory before entering the OS-specific directory. The same is probably true for os/strlcpy.c and os/strlcat.c. Although those files are defenitely candidates for a libtool convenience library. ___ 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 0/2] Build Xi and DPMS stubs as convenience libraries
On 14-02-24 07:07 AM, Jon TURNEY wrote: Jon TURNEY (2): Build dpmsstubs.c once as a convenience library, rather than once for each DDX which wants to use it Build Xi/stubs.c once as a convenience library, rather than once for each DDX which wants to use it Xext/Makefile.am | 4 +++- Xi/Makefile.am | 5 +++-- hw/vfb/Makefile.am | 6 +++--- hw/xnest/Makefile.am | 6 +++--- hw/xwin/Makefile.am | 8 test/Makefile.am | 6 +++--- 6 files changed, 19 insertions(+), 16 deletions(-) Reviewed-by: Gaetan Nadon mems...@videotron.ca And passes distcheck. ___ 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 xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
On 14-02-24 05:27 PM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: Note that we do not need the subdir-objects feature, but automake 2.0 will turn it on any (and it cannot be turned off). We happen to have code that will trip this feature. So we need to fix it before 2.0 gets pervasive. Sure would be nice if automake 2.0 had a compatibility mode that would let us continue with our current scheme. Has anyone looked at the 2.0 code to see if there's a way we can avoid changing how we build things just to make autofu happy? Does not look like there is any new code in git. http://git.savannah.gnu.org/cgit/automake.git Being a 2.0 version, some changes will not be backwards compatible. According to their PLANS, the way it works now is a historical accident and they are determined to correcting it. From the PLANS/subdir-objs.txt file from Automake 1.14 package: The fact that Automake-generated Makefiles place compiled object files in the current directory by default, also when the corresponding source file is in a subdirectory, is basically an historical accident, due to the fact that the 'subdir-objects' option had only been introduced in April 1999, starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never made the default (likely to avoid backwards-compatibility issues). Since I believe the behaviour enabled by the 'subdir-objects' is the most useful one, and in fact the *only* natural one, I'd like to make it the only one available, simplifying the Automake implementation and APIs a little in the process. I originally submitted a patch series which fixes all of the makefiles using git links. It's not the best solution, but it shows it is a reasonable endeavour. Reviewers asked for a better solution which I couldn't provide alone. Jon Turney responded with patches (already reviewed) which fixes most of the DDX code reuse case. That leaves miinitext for which Daniel Stone provided a hint. This is the hardest one. Mark Kettenis suggested how os-support source can be organized and looks fairly simple. I provided a couple patches to fix the test makefile and one of them has already landed in master. In my opinion, this is energy well spent. Time is on our side (rarely happens) as the issue has been detected early thanks to warnings in 1.14. The reusable source code will be better organized, which is not a negligible benefit. ___ 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: Incorrect conditional testing in servermd.h related to linux/arm
On 14-02-20 10:33 AM, Arnaud Fontaine wrote: while compiling mesa on Linux/ARM (and for Linux/ARM), I had a problem with the servermd.h file coming from xorg-server. I found incorrect conditional tests on linux variable while it should be on __linux__ variable. This mistake occurs at several places in the servermd.h file. The attached patch is actually fixing this issue. Grepping the server shows both __linux__ and linux are used, twice as many of the former. On my Ubuntu system: gcc -dM -E - /dev/null | grep linux #define __linux 1 #define __linux__ 1 #define __gnu_linux__ 1 #define linux 1 On a site which I referred to for OS identifying macros: Linux kernel Systems based on the Linux kernel define these macros. There are two major Linux-based operating systems: GNU/Linux and Android, and numerous others like Ångström or OpenEmbedded Type Macro Description Identification __linux__ 1 Identification linux Obsolete (not POSIX compliant) Identification __linux Obsolete (not POSIX compliant) Here is a bug report because __linux__ is not defined: https://bugs.launchpad.net/linaro-android/+bug/868550 A bug report because linux is being checked rather than __linux__ http://bugs.python.org/issue6558 Someone must have the authoritative answer by now, as I have seen this question being asked in 1998. Still cannot easily find an answer. Given that both are used on the server, there would be no arm is using __linux__. It already works every where. Could you amend the commit text to name the compiler you use, and if gcc, provide the list of defines for linux. ___ 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 xserver 0/5] Prepare makefiles for automake 2.0 mandatory subdir-objects
On 14-02-18 12:24 PM, Matthieu Herrb wrote: On Tue, Feb 18, 2014 at 06:09:20PM +0100, Mark Kettenis wrote: Date: Mon, 17 Feb 2014 22:26:17 -0500 From: Gaetan Nadon mems...@videotron.ca On 14-02-17 05:42 PM, Mark Kettenis wrote: Ugh, please no. Can't we just stick to automake 1.x? We can't stop people from using whatever comes with their distro. With automake 2.0, it will break and will submit patches to fix it. Well, given the many incompatible changes, I'm sure distros will continue to provide automake 1.x in some form for the foreseeable future. Yes, for a while. But it means users will have to go out their way to replace it. Patches will be submitted, in all shapes and forms, over and over again. From a practical point of view, some of us import Xorg into other version control systems that don't properly support symlinks. This is interesting. Does the imported X code include Mesa Graphics Library? It already contains links. Examples: ./mesa/mesa/src/gallium/state_trackers/dri/drm/dri_drawable.c ./mesa/mesa/src/mesa/drivers/dri/r200/radeon_span.c Not sure when those links were introduced. We have Mesa 9.2.5 on OpenBSD, but the build process is heavily custumized because the Mesa build doesn't fit in with how we build Xorg on OpenBSD. But I see some evidence that these links are one of the reason why we have this custom build process. This makes it a serious effort for us to deal with Mesa updates. Please don't force us to do the same thing for the xserver. Yes, in OpenBSD's copy of Mesa source tree we don't import symbolic links and deal with VPATH directive in our build system for Mesa. We had to rewrite a build system for Mesa (and a few others components) mainly for 2 reasons: - the existing upstreams build systems relies too heavily on GNU make to be able to patch it locally to be compatible with BSD make. - there are a number of files that are generated by python scripts. Since OpenBSD doesn't have python in the base system, we have to include those generated files in the sources we ship, and provide for developpers who need to touch the original files a way to regenerate the generated files using the ports system's python. Back to the original topic, I think the X server build process needs to be fixed to not require symlinks; There are no symlinks in git in any of the 250 X modules. I've not looked at the exact problem with automake 2.x yet, but adding symlinks looks like the wrong answer. (Unless the goal of automake 2.x is to completely piss off developpers from projects who have not yet switch away from autotools in order to kill the project). This is great feedback. So links are not the ideal solution, in fact, no solution at all for many. To my knowledge, this leaves us with the ideal solution I call code re-factoring to replace the cherry-picking of reusable source files which is exemplified by Jon Turney 's patch earlier in this thread. I've CC Emil Velikov for Mesa who has a bug report for the same issue. I am withdrawing this patch series and turning the problem over to the X server developers. There are 18 makefiles that are broken under automake 2.0 (warnings under 1.14). ___ 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 xserver 0/5] Prepare makefiles for automake 2.0 mandatory subdir-objects
On 14-02-19 12:59 PM, Mark Kettenis wrote: Date: Wed, 19 Feb 2014 12:45:32 -0500 From: Gaetan Nadon mems...@videotron.ca This is great feedback. So links are not the ideal solution, in fact, no solution at all for many. To my knowledge, this leaves us with the ideal solution I call code re-factoring to replace the cherry-picking of reusable source files which is exemplified by Jon Turney 's patch earlier in this thread. I've CC Emil Velikov for Mesa who has a bug report for the same issue. I am withdrawing this patch series and turning the problem over to the X server developers. There are 18 makefiles that are broken under automake 2.0 (warnings under 1.14). Note that not all warnings are actually problems. For example the directories under hw/xfree86/os-support are largely subdir-objects safe. Probably enough to make sure hw/xfree86/os-support/shared gets created in the build directory before entering the OS-specific directory. The same is probably true for os/strlcpy.c and os/strlcat.c. Although those files are defenitely candidates for a libtool convenience library. Yes, various areas of the server code require different solutions. In order to also clear the warnings, the $(srcdir)/../ will half to go. I have seen patches submitted providing workarounds, but if automake does not allow something by design, the implementation can always change and what used to work now doesn't anymore. Thanks. ___ 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 xserver] test: create a link to the generated hw/xfree86/sdksyms.c at build time
Automake 1.14 gives us warning about source code specified in _SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. The test directory needs source from hw/xfree86 which is neither under test nor under a sub directory of test. In 1.14 we get a warning, in 2.0 it will break as it will overwrite the object code in xfree86. The solution in this case is to create a link to hw/xfree86/sdksyms.c at build time. It's just like any other built source file. There are no links created in git. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- test/.gitignore |1 + test/Makefile.am |8 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/test/.gitignore b/test/.gitignore index acbda7a..da86d6e 100644 --- a/test/.gitignore +++ b/test/.gitignore @@ -4,6 +4,7 @@ input list misc os +sdksyms.c string touch xfree86 diff --git a/test/Makefile.am b/test/Makefile.am index 2852bb3..afd8866 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -42,7 +42,7 @@ os_LDADD=$(TEST_LDADD) libxservertest_la_LIBADD = $(XSERVER_LIBS) if XORG -nodist_libxservertest_la_SOURCES = $(top_builddir)/hw/xfree86/sdksyms.c +nodist_libxservertest_la_SOURCES = sdksyms.c libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/loader/libloader.la \ $(top_builddir)/hw/xfree86/os-support/libxorgos.la \ @@ -56,6 +56,12 @@ libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/dixmods/libxorgxkb.la \ @XORG_LIBS@ +BUILT_SOURCES = sdksyms.c +CLEANFILES = sdksyms.c + +sdksyms.c: $(top_builddir)/hw/xfree86/sdksyms.c + $(AM_V_GEN)$(LN_S) $(top_builddir)/hw/xfree86/sdksyms.c + if DRI libxservertest_la_LIBADD += $(top_builddir)/hw/xfree86/dri/libdri.la endif -- 1.7.9.5 ___ 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 xserver] test: remove source file from hashtabletest LDADD
LDADD is for libraries and not for source code. Introduced in commit: ccb3e78124fb05defd0c9b438746b79d84dfc3ae Signed-off-by: Gaetan Nadon mems...@videotron.ca --- test/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/Makefile.am b/test/Makefile.am index afd8866..148cb77 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -36,7 +36,7 @@ fixes_LDADD=$(TEST_LDADD) xfree86_LDADD=$(TEST_LDADD) touch_LDADD=$(TEST_LDADD) signal_logging_LDADD=$(TEST_LDADD) -hashtabletest_LDADD=$(TEST_LDADD) $(top_srcdir)/Xext/hashtable.c +hashtabletest_LDADD=$(TEST_LDADD) os_LDADD=$(TEST_LDADD) libxservertest_la_LIBADD = $(XSERVER_LIBS) -- 1.7.9.5 ___ 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 xserver 1/5] hw: use links in git to share source files due to upcoming automake changes
On 14-02-18 07:35 AM, Jon TURNEY wrote: I'd say if we are building the same object in different places, this is a sign that something else is wrong. I wrote a patch some time ago to build dpmsstubs.c as a convenience library [1], and this would seem to be the better approach to this problem wherever possible. miinitext.c is somewhat a special case as it needs to be built differently for each DDX, but did you consider moving it's contents to a .h file and then #include'ing it in each DDX? Most likely what you propose would be a better technical solution. Not having xserver code knowledge, I am not in a position to pursue such an endeavour, particularly given the large number of Makefiles involved. Not to mention the risk of breaking existing hacks I am not aware of. That's why I thought of this more brain dead mechanical approach which has the merit of being expeditive and does not prevent developers with the know how to replace all or a portion of the links with proper code re-factoring. The patch you mention is dating from 2011, most likely does not apply. You may rework the patch based on patch #1 in this series and I can squash yours and repost the series. Or just append it at the end. Contributions are welcome! ___ 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 xserver 0/5] Prepare makefiles for automake 2.0 mandatory subdir-objects
Automake 1.14 is warning us about upcoming 2.0 making subdir-objects mandatory. This is a feature that has been around for many years but never used in X. This feature is not compatible with the way our makefiles cherry-pick source files from other directories anywhere in the source tree. The subdir-objects feature assumes the path for the source code specified in _SOURCES represents a subdirectory relative to makefile. Dependency tracking uses the path verbatim to create a directory such as '$(top_srcdir)/hw/xfree86' without resolving the variable. The object code will not be generated where the makefile is, but in the same where the source was specified. The proposed solution is to create a link in git for the source files that are shared (fb, mi, xfree86) by multiple directories (kdrive, vfb, ...) I noticed mesa is using links in git and probably other projects as well. They are invited to share their experience. After applying this series of patches, there are no more automake warnings regarding subdir-objects. In addition, the xserver module can be configured and compiled with the subdir-objects feature enabled (as it will be with automake 2.0) and nothing breaks. From the PLANS/subdir-objs.txt file from Automake 1.14 package: The fact that Automake-generated Makefiles place compiled object files in the current directory by default, also when the corresponding source file is in a subdirectory, is basically an historical accident, due to the fact that the 'subdir-objects' option had only been introduced in April 1999, starting with commit 'user-dep-gen-branchpoint-56-g88b5959', and never made the default (likely to avoid backwards-compatibility issues). Since I believe the behaviour enabled by the 'subdir-objects' is the most useful one, and in fact the *only* natural one, I'd like to make it the only one available, simplifying the Automake implementation and APIs a little in the process. The current behaviour where compiled source is located anywhere in the source tree is unknown to automake and probably works by accident. This is an opinion, just to set expectations for anyone who would be hoping to change automake to preserve status quo. Gaetan Nadon (5): hw: use links in git to share source files due to upcoming automake changes test: remove source file from hashtabletest LDADD fb and xi: source files in EXTRA_DIST are redundant xfree86: use links in git to share files due to upcoming automake changes test: create a link to the generated hw/xfree86/sdksyms.c at build time Xi/Makefile.am|1 - fb/Makefile.am|1 - hw/dmx/Makefile.am|6 +++--- hw/dmx/config/Makefile.am |4 ++-- hw/dmx/config/dmxlog.c|1 + hw/dmx/config/strlcpy.c |1 + hw/dmx/fbcmap_mi.c|1 + hw/dmx/miinitext.c|1 + hw/dmx/panoramiX.c|1 + hw/kdrive/src/Makefile.am |4 ++-- hw/kdrive/src/fbcmap_mi.c |1 + hw/kdrive/src/miinitext.c |1 + hw/vfb/Makefile.am|8 hw/vfb/dpmsstubs.c|1 + hw/vfb/fbcmap_mi.c|1 + hw/vfb/miinitext.c|1 + hw/vfb/stubs.c|1 + hw/xfree86/dixmods/Makefile.am|6 +++--- hw/xfree86/dixmods/fbcmap_mi.c|1 + hw/xfree86/dixmods/miinitext.c|1 + hw/xfree86/int10/Makefile.am |4 ++-- hw/xfree86/int10/linux.c |1 + hw/xfree86/int10/linux_vm86.c |1 + hw/xfree86/os-support/bsd/Makefile.am | 22 +++--- hw/xfree86/os-support/bsd/agp_noop.c |1 + hw/xfree86/os-support/bsd/ioperm_noop.c |1 + hw/xfree86/os-support/bsd/kmod_noop.c |1 + hw/xfree86/os-support/bsd/lnx_agp.c |1 + hw/xfree86/os-support/bsd/pm_noop.c |1 + hw/xfree86/os-support/bsd/posix_tty.c |1 + hw/xfree86/os-support/bsd/sigio.c |1 + hw/xfree86/os-support/bsd/vidmem.c|1 + hw/xfree86/os-support/bsd/xf86Axp.c |1 + hw/xfree86/os-support/hurd/Makefile.am| 14 +++--- hw/xfree86/os-support/hurd/VTsw_noop.c|1 + hw/xfree86/os-support/hurd/agp_noop.c |1 + hw/xfree86/os-support/hurd/kmod_noop.c|1 + hw/xfree86/os-support/hurd/pm_noop.c |1 + hw/xfree86/os-support/hurd/posix_tty.c|1 + hw/xfree86/os-support/hurd/sigiostubs.c |1 + hw/xfree86/os-support/hurd/vidmem.c |1 + hw/xfree86/os-support/linux/Makefile.am | 14 +++--- hw/xfree86/os-support/linux/VTsw_usl.c|1 + hw/xfree86/os-support/linux/bios_mmap.c |1 + hw/xfree86/os-support/linux
[PATCH xserver 4/5] xfree86: use links in git to share files due to upcoming automake changes
Automake 1.14 gives us warning about source code specified in *_SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. Automake is warning us because 2.0 version will turn on this feature by default and cannot be turned off. It assumes the object code is to be generated in the subdirs and triggers the subdir-objects feature. The solution the patch proposes is to use links in git to share the source files. So in hw/xfree86/os-support/bsd, kmod_noop.c - ../shared/kmod_noop.c The Makefile will simply lists kmod_noop.c as opposed to $(srcdir)/../shared/kmod_noop.c The will not trigger the subdir-objects feature, even in automake 2.0. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- hw/xfree86/int10/Makefile.am |4 ++-- hw/xfree86/int10/linux.c |1 + hw/xfree86/int10/linux_vm86.c |1 + hw/xfree86/os-support/bsd/Makefile.am | 22 +++--- hw/xfree86/os-support/bsd/agp_noop.c |1 + hw/xfree86/os-support/bsd/ioperm_noop.c |1 + hw/xfree86/os-support/bsd/kmod_noop.c |1 + hw/xfree86/os-support/bsd/lnx_agp.c |1 + hw/xfree86/os-support/bsd/pm_noop.c |1 + hw/xfree86/os-support/bsd/posix_tty.c |1 + hw/xfree86/os-support/bsd/sigio.c |1 + hw/xfree86/os-support/bsd/vidmem.c|1 + hw/xfree86/os-support/bsd/xf86Axp.c |1 + hw/xfree86/os-support/hurd/Makefile.am| 14 +++--- hw/xfree86/os-support/hurd/VTsw_noop.c|1 + hw/xfree86/os-support/hurd/agp_noop.c |1 + hw/xfree86/os-support/hurd/kmod_noop.c|1 + hw/xfree86/os-support/hurd/pm_noop.c |1 + hw/xfree86/os-support/hurd/posix_tty.c|1 + hw/xfree86/os-support/hurd/sigiostubs.c |1 + hw/xfree86/os-support/hurd/vidmem.c |1 + hw/xfree86/os-support/linux/Makefile.am | 14 +++--- hw/xfree86/os-support/linux/VTsw_usl.c|1 + hw/xfree86/os-support/linux/bios_mmap.c |1 + hw/xfree86/os-support/linux/posix_tty.c |1 + hw/xfree86/os-support/linux/sigio.c |1 + hw/xfree86/os-support/linux/vidmem.c |1 + hw/xfree86/os-support/linux/xf86Axp.c |1 + hw/xfree86/os-support/solaris/Makefile.am | 12 ++-- hw/xfree86/os-support/solaris/VTsw_noop.c |1 + hw/xfree86/os-support/solaris/agp_noop.c |1 + hw/xfree86/os-support/solaris/kmod_noop.c |1 + hw/xfree86/os-support/solaris/posix_tty.c |1 + hw/xfree86/os-support/solaris/sigio.c |1 + hw/xfree86/os-support/solaris/vidmem.c|1 + hw/xfree86/os-support/stub/Makefile.am| 16 hw/xfree86/os-support/stub/VTsw_noop.c|1 + hw/xfree86/os-support/stub/agp_noop.c |1 + hw/xfree86/os-support/stub/ioperm_noop.c |1 + hw/xfree86/os-support/stub/kmod_noop.c|1 + hw/xfree86/os-support/stub/pm_noop.c |1 + hw/xfree86/os-support/stub/posix_tty.c|1 + hw/xfree86/os-support/stub/sigio.c|1 + hw/xfree86/os-support/stub/vidmem.c |1 + hw/xfree86/parser/Makefile.am |2 +- hw/xfree86/parser/xprintf.c |1 + hw/xfree86/utils/cvt/Makefile.am |4 ++-- hw/xfree86/utils/cvt/xf86cvt.c|1 + hw/xfree86/utils/cvt/xprintf.c|1 + 49 files changed, 85 insertions(+), 44 deletions(-) create mode 12 hw/xfree86/int10/linux.c create mode 12 hw/xfree86/int10/linux_vm86.c create mode 12 hw/xfree86/os-support/bsd/agp_noop.c create mode 12 hw/xfree86/os-support/bsd/ioperm_noop.c create mode 12 hw/xfree86/os-support/bsd/kmod_noop.c create mode 12 hw/xfree86/os-support/bsd/lnx_agp.c create mode 12 hw/xfree86/os-support/bsd/pm_noop.c create mode 12 hw/xfree86/os-support/bsd/posix_tty.c create mode 12 hw/xfree86/os-support/bsd/sigio.c create mode 12 hw/xfree86/os-support/bsd/vidmem.c create mode 12 hw/xfree86/os-support/bsd/xf86Axp.c create mode 12 hw/xfree86/os-support/hurd/VTsw_noop.c create mode 12 hw/xfree86/os-support/hurd/agp_noop.c create mode 12 hw/xfree86/os-support/hurd/kmod_noop.c create mode 12 hw/xfree86/os-support/hurd/pm_noop.c create mode 12 hw/xfree86/os-support/hurd/posix_tty.c create mode 12 hw/xfree86/os-support/hurd/sigiostubs.c create mode 12 hw/xfree86/os-support/hurd/vidmem.c create mode 12 hw/xfree86/os-support/linux/VTsw_usl.c create mode 12 hw/xfree86/os-support/linux/bios_mmap.c create mode 12 hw/xfree86/os-support/linux/posix_tty.c create mode 12 hw/xfree86/os-support/linux/sigio.c create mode 12 hw/xfree86/os-support/linux/vidmem.c create mode 12 hw/xfree86/os-support/linux/xf86Axp.c create mode 12 hw/xfree86/os-support/solaris/VTsw_noop.c create mode 12 hw/xfree86/os-support/solaris/agp_noop.c create mode 12 hw
[PATCH xserver 1/5] hw: use links in git to share source files due to upcoming automake changes
Automake 1.14 gives us warning about source code specified in *_SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. Automake is warning us because 2.0 version will turn on this feature by default and cannot be turned off. It assumes the object is to be generated in the subdirs and triggers the subdir-objects feature. There are two problems. First, the $(top_srcdir) variable is not expanded, dependency tracking is broken, and the build stops. Second, the object code that is now written where the source file is gets overwritten by the next DDX that shares the source file in its Makefile. An example would hw/dmx and Xext for the panoramiX object code. (It is not a problem today because without subdir-objects being enabled the object code is generated where the Makefile is). The solution the patch proposes is to use links in git to share the source files. So in hw/dmx, miinitext.c - ../../mi/miinitext.c The Makefile will simply lists miinitext.c as opposed to $(top_srcdir)/mi/miinitext.c. The will not trigger the subdir-objects feature, even in automake 2.0. A side-effect of using links is that the tarball contains multiple real copies of miinitext.c rather than several links to a single real file. The build runs fine and you can create a tarball from the expanded tarball. Note on dixmods: The library source was referenced using $(top_builddir) rather than $(top_srcdir) which appears to be a copy/paste error. This should in theory have failed but it didn't. Automake appends a workaround: `test -f '$(top_builddir)/fb/fbcmap_mi.c' || echo '$(srcdir)/'`$(top_builddir)/fb/fbcmap_mi.c Signed-off-by: Gaetan Nadon mems...@videotron.ca --- hw/dmx/Makefile.am |6 +++--- hw/dmx/config/Makefile.am |4 ++-- hw/dmx/config/dmxlog.c |1 + hw/dmx/config/strlcpy.c |1 + hw/dmx/fbcmap_mi.c |1 + hw/dmx/miinitext.c |1 + hw/dmx/panoramiX.c |1 + hw/kdrive/src/Makefile.am |4 ++-- hw/kdrive/src/fbcmap_mi.c |1 + hw/kdrive/src/miinitext.c |1 + hw/vfb/Makefile.am |8 hw/vfb/dpmsstubs.c |1 + hw/vfb/fbcmap_mi.c |1 + hw/vfb/miinitext.c |1 + hw/vfb/stubs.c |1 + hw/xfree86/dixmods/Makefile.am |6 +++--- hw/xfree86/dixmods/fbcmap_mi.c |1 + hw/xfree86/dixmods/miinitext.c |1 + hw/xnest/Makefile.am|8 hw/xnest/dpmsstubs.c|1 + hw/xnest/fbcmap_mi.c|1 + hw/xnest/miinitext.c|1 + hw/xnest/stubs.c|1 + hw/xquartz/Makefile.am |4 ++-- hw/xquartz/fbcmap_mi.c |1 + hw/xquartz/mach-startup/Makefile.am |2 +- hw/xquartz/mach-startup/strndup.c |1 + hw/xquartz/miinitext.c |1 + hw/xwin/Makefile.am |8 hw/xwin/dpmsstubs.c |1 + hw/xwin/fbcmap_mi.c |1 + hw/xwin/miinitext.c |1 + hw/xwin/stubs.c |1 + test/Makefile.am|6 +++--- test/dpmsstubs.c|1 + test/miinitext.c|1 + test/stubs.c|1 + 37 files changed, 55 insertions(+), 28 deletions(-) create mode 12 hw/dmx/config/dmxlog.c create mode 12 hw/dmx/config/strlcpy.c create mode 12 hw/dmx/fbcmap_mi.c create mode 12 hw/dmx/miinitext.c create mode 12 hw/dmx/panoramiX.c create mode 12 hw/kdrive/src/fbcmap_mi.c create mode 12 hw/kdrive/src/miinitext.c create mode 12 hw/vfb/dpmsstubs.c create mode 12 hw/vfb/fbcmap_mi.c create mode 12 hw/vfb/miinitext.c create mode 12 hw/vfb/stubs.c create mode 12 hw/xfree86/dixmods/fbcmap_mi.c create mode 12 hw/xfree86/dixmods/miinitext.c create mode 12 hw/xnest/dpmsstubs.c create mode 12 hw/xnest/fbcmap_mi.c create mode 12 hw/xnest/miinitext.c create mode 12 hw/xnest/stubs.c create mode 12 hw/xquartz/fbcmap_mi.c create mode 12 hw/xquartz/mach-startup/strndup.c create mode 12 hw/xquartz/miinitext.c create mode 12 hw/xwin/dpmsstubs.c create mode 12 hw/xwin/fbcmap_mi.c create mode 12 hw/xwin/miinitext.c create mode 12 hw/xwin/stubs.c create mode 12 test/dpmsstubs.c create mode 12 test/miinitext.c create mode 12 test/stubs.c diff --git a/hw/dmx/Makefile.am b/hw/dmx/Makefile.am index a05af13..dc468a1 100644 --- a/hw/dmx/Makefile.am +++ b/hw/dmx/Makefile.am @@ -3,7 +3,7 @@ SUBDIRS = input config examples doc doxygen man bin_PROGRAMS = Xdmx if XINERAMA -PANORAMIX_SRCS = $(top_srcdir)/Xext/panoramiX.c +PANORAMIX_SRCS
[PATCH xserver 3/5] fb and xi: source files in EXTRA_DIST are redundant
This statement has never been needed. The source files were distributed as they are part of many DDXes libraries. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- Xi/Makefile.am |1 - fb/Makefile.am |1 - 2 files changed, 2 deletions(-) diff --git a/Xi/Makefile.am b/Xi/Makefile.am index af85bd0..b4494e4 100644 --- a/Xi/Makefile.am +++ b/Xi/Makefile.am @@ -107,4 +107,3 @@ libXi_la_SOURCES = \ xiwarppointer.c \ xiwarppointer.h -EXTRA_DIST = stubs.c diff --git a/fb/Makefile.am b/fb/Makefile.am index 89f3bab..f8c4f53 100644 --- a/fb/Makefile.am +++ b/fb/Makefile.am @@ -51,4 +51,3 @@ libfb_la_SOURCES =\ libwfb_la_SOURCES = $(libfb_la_SOURCES) -EXTRA_DIST = fbcmap_mi.c -- 1.7.9.5 ___ 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 xserver 5/5] test: create a link to the generated hw/xfree86/sdksyms.c at build time
Automake 1.14 gives us warning about source code specified in _SOURCES that comes from directories other than the current one. It suggests to enable the subdir-objects feature which only supports code in sub directories. The test directory needs source from hw/xfree86 which is neither under test nor under a sub directory of test. In 1.14 we get a warning, in 2.0 it will break as it will overwrite the object code in xfree86. The solution in this case is to create a link to hw/xfree86/sdksyms.c at build time. It's just like any other built source file. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- test/.gitignore |1 + test/Makefile.am |8 +++- 2 files changed, 8 insertions(+), 1 deletion(-) diff --git a/test/.gitignore b/test/.gitignore index acbda7a..da86d6e 100644 --- a/test/.gitignore +++ b/test/.gitignore @@ -4,6 +4,7 @@ input list misc os +sdksyms.c string touch xfree86 diff --git a/test/Makefile.am b/test/Makefile.am index 1346a88..4679ee7 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -42,7 +42,7 @@ os_LDADD=$(TEST_LDADD) libxservertest_la_LIBADD = $(XSERVER_LIBS) if XORG -nodist_libxservertest_la_SOURCES = $(top_builddir)/hw/xfree86/sdksyms.c +nodist_libxservertest_la_SOURCES = sdksyms.c libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/loader/libloader.la \ $(top_builddir)/hw/xfree86/os-support/libxorgos.la \ @@ -56,6 +56,12 @@ libxservertest_la_LIBADD += \ $(top_builddir)/hw/xfree86/dixmods/libxorgxkb.la \ @XORG_LIBS@ +BUILT_SOURCES = sdksyms.c +CLEANFILES = sdksyms.c + +sdksyms.c: $(top_builddir)/hw/xfree86/sdksyms.c + $(AM_V_GEN)$(LN_S) $(top_builddir)/hw/xfree86/sdksyms.c + if DRI libxservertest_la_LIBADD += $(top_builddir)/hw/xfree86/dri/libdri.la endif -- 1.7.9.5 ___ 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 xserver 2/5] test: remove source file from hashtabletest LDADD
LDADD is for libraries and not for source code. Introduced in commit: ccb3e78124fb05defd0c9b438746b79d84dfc3ae Signed-off-by: Gaetan Nadon mems...@videotron.ca --- test/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/test/Makefile.am b/test/Makefile.am index 5b5700c..1346a88 100644 --- a/test/Makefile.am +++ b/test/Makefile.am @@ -36,7 +36,7 @@ fixes_LDADD=$(TEST_LDADD) xfree86_LDADD=$(TEST_LDADD) touch_LDADD=$(TEST_LDADD) signal_logging_LDADD=$(TEST_LDADD) -hashtabletest_LDADD=$(TEST_LDADD) $(top_srcdir)/Xext/hashtable.c +hashtabletest_LDADD=$(TEST_LDADD) os_LDADD=$(TEST_LDADD) libxservertest_la_LIBADD = $(XSERVER_LIBS) -- 1.7.9.5 ___ 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 xserver 0/5] Prepare makefiles for automake 2.0 mandatory subdir-objects
On 14-02-17 05:42 PM, Mark Kettenis wrote: Ugh, please no. Can't we just stick to automake 1.x? We can't stop people from using whatever comes with their distro. With automake 2.0, it will break and will submit patches to fix it. From a practical point of view, some of us import Xorg into other version control systems that don't properly support symlinks. This is interesting. Does the imported X code include Mesa Graphics Library? It already contains links. Examples: ./mesa/mesa/src/gallium/state_trackers/dri/drm/dri_drawable.c ./mesa/mesa/src/mesa/drivers/dri/r200/radeon_span.c I don't know how the X code is imported in the VCS, it is possible that you get real files instead of links (the tarball does not contain links). Can you apply the first patch and see what happens? Thanks ___ 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
Compiling xserver with --disable-xorg fails in test subdir
make[1]: Entering directory `/home/nadon/xorg/src/xserver/test' ../dix/dix.O: In function `dix_main': /home/nadon/xorg/src/xserver/dix/main.c:200: undefined reference to `InitOutput' /home/nadon/xorg/src/xserver/dix/main.c:264: undefined reference to `InitInput' /home/nadon/xorg/src/xserver/dix/main.c:324: undefined reference to `CloseInput' ./.libs/libxservertest.a(miinitext.o):(.data.rel+0x2e8): undefined reference to `present_extension_init' --disable-xorg is the only option I used. I tried adding --disable-present but it did not help. ___ 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] Enable subdir-objects
On 14-02-13 03:51 AM, Thierry Reding wrote: On Wed, Feb 12, 2014 at 08:33:21PM -0500, Gaetan Nadon wrote: On 14-02-12 05:50 PM, Gaetan Nadon wrote: If the automake defined variables $(top_srcdir) does not work, then something is seriously broken and the root cause should be found, not worked around :-) A lot has been written about this already. I was able to reproduce the problem with 1.11. Various workarounds have been proposed, and it is still not clear if it is a bug in Automake or something else we miss. I would just stay away from it for now. Alright, I'll drop that patch and live with the autoreconf warnings then. Thanks for taking the time to investigate so thoroughly. Thierry I am reading the Automake mailing lists. It looks like it is not a good idea of using top_srcdir to pick source code here and there in different subdirs. What they are trying to do is to rectify the situation in 2.0 by making subdir-objects mandatory which is what should have been the (only) behaviour all along. Bottom line is that we have to do something nicer before 2.0 hit the streets. Thanks for your patience. ___ 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 xserver] config: fails to create tarball as xorg-server.conf file removed
Just need to update EXTRA_DIST Signed-off-by: Gaetan Nadon mems...@videotron.ca --- config/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/Makefile.am b/config/Makefile.am index e0f0a8d..c6350be 100644 --- a/config/Makefile.am +++ b/config/Makefile.am @@ -38,4 +38,4 @@ endif # !CONFIG_HAL endif # !CONFIG_UDEV -EXTRA_DIST = xorg-server.conf x11-input.fdi 10-evdev.conf non-seat0.conf.multi-seat fdi2iclass.py 10-quirks.conf +EXTRA_DIST = x11-input.fdi 10-evdev.conf non-seat0.conf.multi-seat fdi2iclass.py 10-quirks.conf -- 1.7.9.5 ___ 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 xserver] config: fails to create tarball as xorg-server.conf file removed
Just need to update EXTRA_DIST Reviewed-by: Peter Hutterer peter.hutte...@who-t.net Signed-off-by: Gaetan Nadon mems...@videotron.ca --- config/Makefile.am |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/Makefile.am b/config/Makefile.am index e0f0a8d..c6350be 100644 --- a/config/Makefile.am +++ b/config/Makefile.am @@ -38,4 +38,4 @@ endif # !CONFIG_HAL endif # !CONFIG_UDEV -EXTRA_DIST = xorg-server.conf x11-input.fdi 10-evdev.conf non-seat0.conf.multi-seat fdi2iclass.py 10-quirks.conf +EXTRA_DIST = x11-input.fdi 10-evdev.conf non-seat0.conf.multi-seat fdi2iclass.py 10-quirks.conf -- 1.7.9.5 ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-11 10:47 PM, Keith Packard wrote: Oh, right, I remember this from fontconfig -- ubuntu sets _FORTIFY_SOURCE by default. I'd love to use this in the X server by default, but I'm concerned that we'll end up breaking builds on ubuntu if we unilaterally define it. Can you see what your build does with $ make CC=gcc -D_FORTIFY_SOURCE=2 First, I need to correct a mistake: the O/S is the unreleased 14-04 version. The 13-10 version contains gcc 4.8.1 and I wanted 4.8.2 for the test. I need a clean build of the xserver module. On gcc 4.8.2, (Ubuntu 14-04) I get a complete clean build. On gcc 4.6.3 (Ubuntu 12-04), I get the following error in hw/vfb when linking ../../Xext/.libs/libXext.a(xvmc.o): In function `xf86XvMCRegisterDRInfo': /home/nadon/xorg/src/xserver/Xext/xvmc.c:808: undefined reference to `strlcpy' /home/nadon/xorg/src/xserver/Xext/xvmc.c:809: undefined reference to `strlcpy' ../../os/os.O: In function `siHostnameAddrMatch': /home/nadon/xorg/src/xserver/os/access.c:1683: undefined reference to `strlcpy' ../../os/os.O: In function `AuthAudit': /home/nadon/xorg/src/xserver/os/connection.c:540: undefined reference to `strlcpy' /home/nadon/xorg/src/xserver/os/connection.c:559: undefined reference to `strlcpy' ../../os/os.O:/home/nadon/xorg/src/xserver/os/log.c:870: more undefined references to `strlcpy' follow if it works, then we'd be find setting it for all gcc builds, otherwise we'll need magic. It could be optional if we add this feature to the --enable-strict-compilation we have on every module. Here's a patch which cleans up all of the -Wunused-result warnings I'm getting with -D_FORTIFY_SOURCE=2. I haven't tried running this server... The patch works as advertized. Too many code changes for me to give a rb. I did manage to start X however. Tested-by: Gaetan Nadon mems...@videotron.ca ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-12 12:57 PM, Keith Packard wrote: This function is supposed to be automatically replaced with os/strlcpy.c when not present in your C library. Something appears to be amiss here; I don't have strlcpy *or* strlcat in my glibc, and so configure correctly adds os/strlcpy.c and os/strlcat.c to the build. I cannot reproduce the problem anymore. I retraced my commands from the terminal, run make CC=gcc -D_FORTIFY_SOURCE=2 again, this time it works. This shows it is already defined: nadon@memsize:~/xorg/src/app/xclock$ gcc -dM -E - /dev/null | grep FORTIFY #define _FORTIFY_SOURCE 2 There does not seem to be any harm in defining for all builds. If it is not supported, it will be ignored. Let me know, and I can create a patch to add this in util-macros. It can be conditionally added using AC_CHECK_DECLS. If it is already define, it won't be added. ___ 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] Enable subdir-objects
On 14-02-12 11:15 AM, Thierry Reding wrote: automake complains about the subdir-objects being missing. Enabling it, Is automake issuing a real warning or just making a suggestion? however, causes various build issues to pop up because $(srcdir), $(top_srcdir), $(builddir) and $(top_builddir) aren't handled properly. It's simple to work around it by substituting them for their actual values, though. Signed-off-by: Thierry Reding tred...@nvidia.com --- configure.ac| 2 +- hw/vfb/Makefile.am | 8 hw/xfree86/dixmods/Makefile.am | 6 +++--- hw/xfree86/int10/Makefile.am| 4 ++-- hw/xfree86/os-support/linux/Makefile.am | 16 hw/xfree86/parser/Makefile.am | 2 +- hw/xfree86/utils/cvt/Makefile.am| 4 ++-- hw/xnest/Makefile.am| 8 test/Makefile.am| 8 9 files changed, 29 insertions(+), 29 deletions(-) diff --git a/configure.ac b/configure.ac index 21a659141bc9..d135cb2b38c2 100644 --- a/configure.ac +++ b/configure.ac @@ -31,7 +31,7 @@ RELEASE_DATE=2014-01-09 RELEASE_NAME=Golden Gaytime AC_CONFIG_SRCDIR([Makefile.am]) AC_CONFIG_MACRO_DIR([m4]) -AM_INIT_AUTOMAKE([foreign dist-bzip2]) +AM_INIT_AUTOMAKE([foreign dist-bzip2 subdir-objects]) AC_USE_SYSTEM_EXTENSIONS # Require xorg-macros minimum of 1.14 for XORG_COMPILER_BRAND in XORG_DEFAULT_OPTIONS diff --git a/hw/vfb/Makefile.am b/hw/vfb/Makefile.am index 9f4992c8b7f1..ceb418388505 100644 --- a/hw/vfb/Makefile.am +++ b/hw/vfb/Makefile.am @@ -9,12 +9,12 @@ AM_CFLAGS = -DHAVE_DIX_CONFIG_H \ SRCS = InitInput.c \ InitOutput.c \ - $(top_srcdir)/Xext/dpmsstubs.c \ - $(top_srcdir)/Xi/stubs.c \ - $(top_srcdir)/mi/miinitext.c + ../../Xext/dpmsstubs.c \ + ../../Xi/stubs.c \ + ../../mi/miinitext.c No, No, please No!!! For full disclosure, I spent months replacing those ../ in all the 250 modules. Automake recommend against use these ../ and there are scenarios where it breaks. If the automake defined variables $(top_srcdir) does not work, then something is seriously broken and the root cause should be found, not worked around :-) You are probably running automake 1.14. The current code works fine on automake 1.10 and later. I think they are suggesting using a new feature in 1.14, which is not available in versions prior to automake 1.14. The X.Org minimum version is now 1.11 which means no features newer than 1.11 should be used. There are other situations where 1.14 make recommendations, which if applied, break on earlier versions. This is a pain for well meaning developers who want to make improvements. It happens regularly. They don't think code has to be backward compatible. Ok, so back to basics. If you limit your patch to enable subdir-objects, does it work with 1.11? If the feature is not avaiable at that level then you cannot use it. I would have to look it up. If it works on 1.11 but breaks on 1.14, then lets not work around and put up with the suggestions. Eventually someone will fix 1.14. I'll take some more to look into this. Sorry if I am a bit hasty for now. ___ 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] Enable subdir-objects
On 14-02-12 05:50 PM, Gaetan Nadon wrote: +AM_INIT_AUTOMAKE([foreign dist-bzip2 subdir-objects]) This is not a new feature in 1.14, but it has never been used so far. All 250 X modules have the same line. If you want to propose this, as it changes all of xserver, you would have to test all 98 makefiles in xserver. Some of them are fairly complex and I doubt the change would be easy. I don't have personal experience with subdir-objects feature, I'll have a go at it. It's hard to believe that $(top_srcdir) would not work anymore. There are most likely other changes to do in the makefiles, other than just turning on the feature. Ok here is a good explanation, as someone already reported this: https://bugs.freedesktop.org/show_bug.cgi?id=69874 New in 1.14: ... - The next major Automake version (2.0) will unconditionally activate the 'subdir-objects' option. In order to smooth out the transition, we now give a warning (in the category 'unsupported') whenever a source file is present in a subdirectory but the 'subdir-object' is not enabled. For example, the following usage will trigger such a warning: bin_PROGRAMS = sub/foo sub_foo_SOURCES = sub/main.c sub/bar.c Long story short, we can ignore it until 2.0 is out, or unconditionally set it in configure.ac. The latter one may be preffered in order for us to test and make sure that mesa builds correctly, otherwise we'll be badly surprised as automake 2.0 comes out (think bleeding edge distros/packagers reporting a dozen of bugs) Looks like we will have to do something about it, but it can't be blasting ../../../ by the millions :-) ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-12 06:24 PM, Keith Packard wrote: So, we could simply add #ifndef _FORTIFY_SOURCE #define _FORTIFY_SOURCE 2 #endif to some X server header file, or you could do something fancier with the configure macros. I'm easy, but I definitely want it somehow :-) How about this for a start. If it works fine we can apply it to all modules through util-macros where we can be a little fancier if need be, like taking care of non GNU compilers. diff --git a/configure.ac b/configure.ac index 21a6591..66dd24f 100644 --- a/configure.ac +++ b/configure.ac @@ -85,7 +85,7 @@ XORG_PROG_RAWCPP # Quoted so that make will expand $(CWARNFLAGS) in makefiles to allow # easier overrides at build time. -XSERVER_CFLAGS='$(CWARNFLAGS)' +XSERVER_CFLAGS='$(CWARNFLAGS) -D_FORTIFY_SOURCE=2' dnl Explicitly add -fno-strict-aliasing since this option should disappear dnl from util-macros CWARNFLAGS ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-12 07:37 PM, Peter Hutterer wrote: just an issue with incomplete builds, happens to me when I rebase or switch branches. make clean in os/ usually does the job, otherwise autoreconf/configure definitely does. yep, I rebased, applied a patch, ran ./configure (but not autogen) Thanks ___ 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] Enable subdir-objects
On 14-02-12 05:50 PM, Gaetan Nadon wrote: If the automake defined variables $(top_srcdir) does not work, then something is seriously broken and the root cause should be found, not worked around :-) A lot has been written about this already. I was able to reproduce the problem with 1.11. Various workarounds have been proposed, and it is still not clear if it is a bug in Automake or something else we miss. I would just stay away from it for now. ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-11 12:08 AM, Keith Packard wrote: It's not just the GCC version, unfortunately. I have a pile of versions, and cannot generate any of the (useful) warnings that you have managed to elicit from the compiler. I tried Ubuntu 13-10 with gcc 4.8.2. The 32-bit version 35 -Wunused-result 0 -Wpointer-arith(as expected) 0 -Wformat (you have 1) 1 -Wunused-function On the 64 bit with gcc 4.6.3: 35 -Wunused-result 2 -Wpointer-arith 2 -Wformat 1 -Wunused-function ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-09 07:03 PM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: I have a total of 242 warnings. 202-Wshadow 35 -Wunused-result 2 -Wpointer-arith 2 -Wformat 1 -Wunused-function Are you running the latest headers, libraries, mesa and X server bits? Yes, just did another run with a few new commits I have a total of 238 warnings. 199 -Wshadow 35 -Wunused-result 2 -Wpointer-arith 1 -Wformat 1 -Wunused-function Build log available at: *http://people.freedesktop.org/~gnadon/xserver.html* The only successful build I see on tinderbox is from CYGWIN, but looks significantly different: http://tinderbox.x.org/builds/2014-02-08-0011/ ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-10 06:36 PM, Alan Coopersmith wrote: I believe the ones about shadowing system functions like index are silenced in newer gcc versions - for instance I see them with gcc 4.5 but not 4.7. Which gcc did you use in this build? gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3. From Ubuntu 12.04 LTS. ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-10 06:57 PM, Keith Packard wrote:
Gaetan Nadon mems...@videotron.ca writes:
Ok, except for -Wshadow, these are all legitimate warnings (and a few
actual bugs!) that we should fix. I would love for someone to explain
why my build doesn't generate the useful warnings and why Gaedon's
compiler is generating the -Wshadow ones...
Thanks, Gaedon!
I have a total of 238 warnings.
199 -Wshadow
All of these are badly named libc/libm functions:
y0
y1
gamma
index
remainder
I am not seeing any -Wshadow warnings between functions and local
variables. This example:
double z1;
double y1(double x) { return 0; }
void foo (void) {
int z1 = 0;
int y1 = 0;
}
Generates a single warning for me:
$ cc -Wshadow -c foo.c
foo.c: In function ‘foo’:
foo.c:6:6: warning: declaration of ‘z1’ shadows a global declaration
[-Wshadow]
int z1 = 0;
^
foo.c:1:8: warning: shadowed declaration is here [-Wshadow]
double z1;
^
nadon@memsize:~/xorg/src$ cc -Wshadow -c foo.c
foo.c: In function ‘foo’:
foo.c:6:6: warning: declaration of ‘z1’ shadows a global declaration
[-Wshadow]
foo.c:1:8: warning: shadowed declaration is here [-Wshadow]
foo.c:7:6: warning: declaration of ‘y1’ shadows a global declaration
[-Wshadow]
foo.c:3:8: warning: shadowed declaration is here [-Wshadow]
What version of gcc are you using? And, what compiler flags do you end
up with?
$ gcc --version
gcc (Debian 4.8.2-14) 4.8.2
$ make V=1
gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../include -DHAVE_DIX_CONFIG_H
-Wall -Wpointer-arith -Wmissing-declarations -Wformat=2 -Wstrict-prototypes
-Wmissing-prototypes -Wnested-externs -Wbad-function-cast
-Wold-style-definition -Wdeclaration-after-statement -Wunused -Wuninitialized
-Wshadow -Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls
-Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self -Werror=main
-Werror=missing-braces -Werror=sequence-point -Werror=return-type
-Werror=trigraphs -Werror=array-bounds -Werror=write-strings -Werror=address
-Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -fno-strict-aliasing
-fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
-I/local/xorg/include -I/local/xorg/include/pixman-1
-I/local/xorg/include/X11/dri -I/local/xorg/include/libdrm
-I/usr/include/freetype2 -I../include -I../include -I../Xext -I../composite
-I../damageext -I../xfixes -I../Xi -I../mi -I../miext/sync -I../miext/shadow
-I../miext/damage -I../render -I../randr -I../fb -I../dbe -I../present
-fvisibility=hidden -O2 -g -MT mitrap.lo -MD -MP -MF .deps/mitrap.Tpo -c
mitrap.c -fPIC -DPIC -o .libs/mitrap.o
nadon@memsize:~/xorg/src/xserver/render$ gcc --version
gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
nadon@memsize:~/xorg/src/xserver/render$ rm -f mitrap.lo
nadon@memsize:~/xorg/src/xserver/render$ make V=1
/bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu99
-DHAVE_CONFIG_H -I. -I../include-DHAVE_DIX_CONFIG_H -Wall
-Wpointer-arith -Wmissing-declarations -Wformat=2
-Wstrict-prototypes -Wmissing-prototypes -Wnested-externs
-Wbad-function-cast -Wold-style-definition
-Wdeclaration-after-statement -Wunused -Wuninitialized -Wshadow
-Wmissing-noreturn -Wmissing-format-attribute -Wredundant-decls
-Wlogical-op -Werror=implicit -Werror=nonnull -Werror=init-self
-Werror=main -Werror=missing-braces -Werror=sequence-point
-Werror=return-type -Werror=trigraphs -Werror=array-bounds
-Werror=write-strings -Werror=address -Werror=int-to-pointer-cast
-Werror=pointer-to-int-cast -fno-strict-aliasing
-fno-strict-aliasing -D_BSD_SOURCE -DHAS_FCHOWN -DHAS_STICKY_DIR_BIT
-I/home/nadon/xorg/inst/include
-I/home/nadon/xorg/inst/include/pixman-1
-I/home/nadon/xorg/inst/include/X11/dri
-I/home/nadon/xorg/inst/include/libdrm -I/usr/include/freetype2
-I../include -I../include -I../Xext -I../composite -I../damageext
-I../xfixes -I../Xi -I../mi -I../miext/sync -I../miext/shadow
-I../miext/damage -I../render -I../randr -I../fb -I../dbe
-I../present -fvisibility=hidden -g -O2 -MT mitrap.lo -MD -MP -MF
.deps/mitrap.Tpo -c -o mitrap.lo mitrap.c
I checked the list of warnings flags and include directives are the same
as expected.
We need to get the compiler to stop emiting these warnings as it's just
not reasonable to require that local variables not have the name 'y1' or
'index'. I'm very resistant to asserting that these are bugs in the X
Re: [PULL] button mapping fix and unconstify patches
On 14-02-09 05:55 AM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: |||Perhaps some of its companions could be re-instated as well, should the xserver code base now be considered fully modernized? Patches to make the X server compile without warning would really be nice to have before these are turned on. I'm really not interested in seeing compiler warnings any more, as that obscures warnings caused by incoming code changes. And, I don't want to run a custom set of compiler flags, but if the default set gets changed and the X server emits a pile of warnings as a result, I will be sad. Ok, so the recent patch wave did not also address all commented out warning flags. Just asking in case some of them needed to be re-instated. Thanks ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-09 02:12 PM, Keith Packard wrote: If you can reproduce this on your machine (and, I hope that is trivial), then you should feel free to play with compiler flags and send email to the list about what you find; if the pain threshold isn't too high, we can fix the warnings and add the flags to the default set. Alternatively, you could file bugs with the results. I vaguely recall you mentioned you are operating from a 32 bit computer. Here is my output on Ubuntu x86_64: make[1]: Entering directory `/home/nadon/xorg/src/xserver/glx' CC indirect_dispatch.lo CC indirect_dispatch_swap.lo CC indirect_reqsize.lo CC indirect_size_get.lo indirect_dispatch_swap.c:85:1: warning: 'bswap_CARD64' defined but not used [-Wunused-function] The string logical does not come up. I have a total of 242 warnings. 202-Wshadow 35 -Wunused-result 2 -Wpointer-arith 2 -Wformat 1 -Wunused-function I found no -Wlogical-op . ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-09 02:42 PM, Alan Coopersmith wrote: On 02/ 9/14 11:12 AM, Keith Packard wrote: Gaetan Nadon mems...@videotron.ca writes: Ok, so the recent patch wave did not also address all commented out warning flags. Just asking in case some of them needed to be re-instated. With Alan's -Wlogical-op change, I still have only a single warning (bswap_CARD64 in indirect_dispatch_swap.c). Hmm, I don't see that, probably because the bswap_64 macro it uses is platform specific. 32 bit computer perhaps. I found only these, on a full jhbuild in libxkbfile: xkbmisc.c:100:13: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op] xkbmisc.c:114:13: warning: logical 'and' of mutually exclusive tests is always false [-Wlogical-op] ___ 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 RESEND2 xserver] Default font path: remove the check for ${sysconfdir}/X11/fontpath.d
On 14-02-07 10:05 PM, Keith Packard wrote:
Gaetan Nadon mems...@videotron.ca writes:
The location ${sysconfdir}/X11/fontpath.d is unknown at configuration time
(only at make time) as evidenced by the configuration output:
checking for ${prefix}/etc/X11/fontpath.d... no
Unlike font-util for the X fonts, there is no mechanism to query where
fontpath.d is. Fedora have chosen /etc/X11 and others have followed, but this
is not a standard. It might also be installed at another location, it may or
may
not be under the xserver installation prefix. We just don't know. Debian does
not use this at all.
Distros are using --with-default-path when they support fontpath.d, so they
never relied on the server default as it never worked.
I'd like to get some review from people familiar with the distro
packaging process to understand if this analysis is accurate; I haven't
any way to know what the effect of this change would be otherwise.
I would like to as well. The dead code is trying to implement a feature,
so we can remove the dead code, or try to fix it. My investigation lead
me to believe that the feature is not implementable, so the patch just
removes the dead code.
If we don't hear from anyone regarding a proper implementation of the
feature, I suggest applying the patch. Given it is dead code and has
never worked since inception 4 years ago, the risk is zero.
Thanks!
___
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] glx: Ignore unused function warnings
On 14-02-07 07:10 PM, Keith Packard wrote: indirect_dispatch_swap.c, which is autogenerated from a mesa script, contains the function 'bswap_CARD64', which is never used in the file. While it would be nice to fix this upstream, that's hard, so this change causes these warnings to be ignored for just this directory. Signed-off-by: Keith Packard kei...@keithp.com --- glx/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/glx/Makefile.am b/glx/Makefile.am index 54e8140..9838581 100644 --- a/glx/Makefile.am +++ b/glx/Makefile.am @@ -27,6 +27,8 @@ if DRI2_AIGLX AM_CPPFLAGS += -I$(top_srcdir)/hw/xfree86/dri2 endif +AM_CFLAGS += -Wno-unused-function + indirect_sources = \ indirect_dispatch.c \ indirect_dispatch.h \ Works only for the GNU compiler. The util-macros XORG_COMPILER_FLAGS uses XORG_TESTSET_CFLAG to test each flag we use for compiler support. This is the reason why you see this type of line at configure time: checking if gcc -std=gnu99 supports -Wall... yes To introduce a new compiler flag, add an XORG_TESTSET_CFLAG statement in configure.ac such as: XORG_TESTSET_CFLAG ([NO_UNUSED_FUNCTION], [-Wno-unused-function solaris-equivalent-if-any]) Each flag is tested in the set and the first one that works is accepted. In the Makefile: +AM_CFLAGS += $(NO_UNUSED_FUNCTION) You should then see at config time: checking if gcc -std=gnu99 supports -Wno-unused-function... yes If there is no equivalent on Solaris, the variable NO_UNUSED_FUNCTION will be empty. If -Wno-unused-function is accepted on Solaris, it will be used. This is the first time a warning flag is added to the comprehensive set we already provide through util-macros. ___ 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 util-macros 2/2] Add XORG_WITH_M4 macro
From: Arnaud Fontaine ar...@debian.org Originally from XCB, this macro checks for the presence of m4 or gm4 which supports -I dir. The AC_PATH_PROGS_FEATURE_CHECK autoconf macro requires autoconf 2.62. Signed-off-by: Gaetan Nadon mems...@videotron.ca --- xorg-macros.m4.in | 23 +++ 1 file changed, 23 insertions(+) diff --git a/xorg-macros.m4.in b/xorg-macros.m4.in index 200a36b..1680f32 100644 --- a/xorg-macros.m4.in +++ b/xorg-macros.m4.in @@ -882,6 +882,29 @@ fi]) AM_CONDITIONAL([HAVE_FOP], [test $have_fop = yes]) ]) # XORG_WITH_FOP +# XORG_WITH_M4([MIN-VERSION]) +# --- +# Minimum version: 1.19.0 +# +# This macro attempts to locate an m4 macro processor which supports +# -I option and is only useful for modules relying on M4 in order to +# expand macros in source code files. +# +# Interface to module: +# M4: returns the path of the m4 program found +# returns the path set by the user in the environment +# +AC_DEFUN([XORG_WITH_M4], [ +AC_CACHE_CHECK([for m4 that supports -I option], [ac_cv_path_M4], + [AC_PATH_PROGS_FEATURE_CHECK([M4], [m4 gm4], + [[$ac_path_M4 -I. /dev/null /dev/null 21 \ + ac_cv_path_M4=$ac_path_M4 ac_path_M4_found=:]], + [AC_MSG_ERROR([could not find m4 that supports -I option])], + [$PATH:/usr/gnu/bin])]) + +AC_SUBST([M4], [$ac_cv_path_M4]) +]) # XORG_WITH_M4 + # XORG_WITH_PS2PDF([DEFAULT]) # # Minimum version: 1.6.0 -- 1.7.9.5 ___ 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: [RFC] X.Org minimum requirements for Autotools policy review
On 13-10-24 02:17 PM, Gaetan Nadon wrote: Recommendations 1. We should prereq libtool 2.2 as a minimum (available since 2008). This has been implemented in the server and I haven't heard of any complaints. 1. We should prereq autoconf 2.62 as a minimum (available since 2008). Keeps us in the same time period and is required by automake 1.11. 2. We should prereq automake 1.11 (available since 2009). Keeps us in the same time period. No strong objections (we already have have mesa/drm at that level), l'll update the wiki and util-macros. This will be the smoke test. ___ 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 util-macros] Bump minimum Autoconf required version to 2.62
The main motivation is to catch-up with the development reality and allow use of features in Autoconf 2.62 as well as Automake 1.11. As usual this means no features found only in versions above those specified are allowed. This is implementing the policy change which is described in: http://www.x.org/wiki/Building_the_X_Window_System/?updated#index2h3 Discussion on xorg minimum autotools requirements: http://lists.x.org/archives/xorg-devel/2013-October/038325.html Signed-off-by: Gaetan Nadon mems...@videotron.ca --- configure.ac |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 6d52b10..a412445 100644 --- a/configure.ac +++ b/configure.ac @@ -21,7 +21,7 @@ dnl CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. dnl dnl Process this file with autoconf to create configure. -AC_PREREQ([2.60]) +AC_PREREQ([2.62]) AC_INIT([util-macros], [1.18.0], [https://bugs.freedesktop.org/enter_bug.cgi?product=xorg], -- 1.7.9.5 ___ 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: [PULL] button mapping fix and unconstify patches
On 14-02-05 03:25 AM, Keith Packard wrote: With this hidesight, I think now what I should have done is to cast at the assignment of the string constant and leave the types alone. Then, compiling with -Wcast-qual would have quickly identified all places in the code which needed fixes like those Peter has done here. I'm willing to change things over to this style if that seems like a useful step towards eliminating this particular class of coding issues? If need be, I am willing to revert the patch that moved Wcast-qual to the commented out section. |# These are currently disabled because they are noisy. They will be enabled # in the future once the codebase is sufficiently modernized to silence # them. For now, I don't want them to drown out the other warnings. # XORG_TESTSET_CFLAG([[BASE_]PREFIX[FLAGS]], [-Wlogical-op]) # XORG_TESTSET_CFLAG([[BASE_]PREFIX[FLAGS]], [-Wparentheses]) # XORG_TESTSET_CFLAG([[BASE_]PREFIX[FLAGS]], [-Wcast-align]) # XORG_TESTSET_CFLAG([[BASE_]PREFIX[FLAGS]], [-Wcast-qual])| || |||Perhaps some of its companions could be re-instated as well, should the xserver code base now be considered fully modernized? | ___ 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 xkbcomp] man: replace default include directory with the one from configure
On 14-02-02 04:31 PM, Peter Hutterer wrote: Signed-off-by: Peter Hutterer peter.hutte...@who-t.net --- man/Makefile.am | 2 ++ man/xkbcomp.man | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) Reviewed-by: Gaetan Nadon mems...@videotron.ca ___ 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 xfs 1/3] Warning fixes.
On 14-01-29 04:14 PM, Keith Packard wrote: XFS replicates quite a bit of X server infrastructure so that it can share libXfont. Many of those shared functions are declared in shared font header files (either fontsproto.h or fontmisc.h). This patch removes duplicate definitions from the XFS header files and makes sure the shared header files are included in the right places to get the functions declared before being defined. Of course, some of those function types have changed, in particular CopyISOLatin1Lowered now takes a const char * source parameter. This patch also stops re-using the 'port' variable in GetInetdListenInfo when fetching the ReopenInfo. That's not strictly necessary here, but will be useful when the Reopen API in libxtrans changes to take a constant parameter. Signed-off-by: Keith Packard kei...@keithp.com Applies and fixes compile error. Tested-by: Gaetan Nadon mems...@videotron.ca ___ 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] Replace 'pointer' with the equivalent 'void *'.
On 14-01-27 04:59 PM, Keith Packard wrote: Cool. Any comments on the libXfont patch, or should I just push it? I had not tried it (confusion on my part), but it fails for me as it does for Knut. ___ 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
