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 > Signed-off-by: Andreas Boll > --- > 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 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 > --- > 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 @@ > > > > + > > > 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. - ___ 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 --- 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 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 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 --- 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 --- 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
[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 --- 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 2>&1; 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
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 2>&1 ; then
defaults write $X11_PREFS_DOMAIN cache_fonts -bool true
fi
if ! defaults read $X11_PREFS_DOMAIN no_auth > /dev/null 2>&1 ; then
defaults write $X11_PREFS_DOMAIN no_auth -bool false
fi
if ! defaults read $X11_PREFS_DOMAIN nolisten_tcp > /dev/null 2>&1 ;
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="$de
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 >> --- >> 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
> 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
>
> Modified by Alan Coopersmith to handle gpg vs. gpg2 paths for Solaris.
>
> Signed-off-by: Alan Coopersmith
> ---
> 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 1>&2
> + 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 "
1024-bit DSA key, ID FB9EC9FC, created 2008-12-16
Not a big deal,
Reviewed-by: Gaetan Nadon
___
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 > --- > 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 ___ 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
> ---
> 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 2/2] Xorg.wrap manpages: use __appmansuffix__ instead of hardcoding 1
On 14-04-18 05:31 AM, Hans de Goede wrote: > Cc: Gaetan Nadon > Signed-off-by: Hans de Goede > --- > hw/xfree86/man/Xorg.wrap.man | 4 ++-- > hw/xfree86/man/Xwrapper.config.man | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/hw/xfree86/man/Xorg.wrap.man b/hw/xfree86/man/Xorg.wrap.man > index f2153e3..58937c7 100644 > --- a/hw/xfree86/man/Xorg.wrap.man > +++ b/hw/xfree86/man/Xorg.wrap.man > @@ -1,4 +1,4 @@ > -.\" Xwrapper.wrap.1 > +.\" Xwrapper.wrap.__appmansuffix__ > .\" > .\" Copyright 2014 Red Hat, Inc. > .\" > @@ -26,7 +26,7 @@ > .\" > .\" shorthand for double quote that works everywhere. > .ds q \N'34' > -.TH Xorg.wrap 1 __xorgversion__ > +.TH Xorg.wrap __appmansuffix__ __xorgversion__ > .SH NAME > Xorg.wrap \- Xorg X server binary wrapper > .SH DESCRIPTION > diff --git a/hw/xfree86/man/Xwrapper.config.man > b/hw/xfree86/man/Xwrapper.config.man > index 800947c..5c777c9 100644 > --- a/hw/xfree86/man/Xwrapper.config.man > +++ b/hw/xfree86/man/Xwrapper.config.man > @@ -1 +1 @@ > -.so man1/Xorg.wrap.1 > +.so man__appmansuffix__/Xorg.wrap.__appmansuffix__ If you can display both man pages showing the correct section number. Reviewed-by: Gaetan Nadon ___ 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 > > Cc: Gaetan Nadon > Signed-off-by: Hans de Goede > --- > 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 ___ 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: Xwayland DDX: build breaks in configuration
On 14-04-08 12:35 PM, Kristian Høgsberg wrote: > %-protocol.c : %.xml > $(AM_V_GEN)$(WAYLAND_SCANNER) code < $< > $@ > > %-client-protocol.h : %.xml > $(AM_V_GEN)$(WAYLAND_SCANNER) client-header < $< > $@ > > Anyway, patch is on the list to remove the configure.ac macro along > with patches to build without GLX and xshmfence. Great. Just a reminder to list the names of the generated files in the .gitignore file where the Makefile is. ___ 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 > --- > 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 ___ 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 07:50 PM, Yaakov (Cygwin/X) wrote: > You're referring to using CFLAGS instead of AM_CFLAGS in automake > files. This is appending to (not clobbering) CFLAGS at the configure > level, which still allows the user to override the settings during > make (even though it would be a bad idea if they left out these flags). > Correct. I am not worried that it will not work. Over the years I have seen many patches removing the use of CFLAG in modules. I looked in the current server configuration file and cygwin is the only one using CFLAGS (-DFD_SETSIZE=256). It tends to confirm that the "Variables reserved for the users" are indeed observed. *3.6 Variables reserved for the user* Some Makefile variables are reserved by the GNU Coding Standards for the use of the "user"---the person building the package. For instance, CFLAGS is one such variable. Sometimes package developers are tempted to set user variables such as CFLAGS because it appears to make their job easier. Aside from the automake design point, isn't there a risk when using "global" C flags (or LD flags) for all makefiles? Name clashing in #define or picking up a symbol from the wrong library? Anyway, I leave it up to you. Never really had a chance to discuss this topic before. 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 xinit] startx: Pass vtX as long as the user did not specify one
On 14-04-07 07:42 AM, James Cloos wrote: > But re commit 44915d6953076, > > HG> tty_num=$(echo "$tty" | grep -oE '[0-9]+$') > > Is grep -o available everwhere startx(1) runs? > > The posix page, grep.1p, does not mention -o. > > It looks like each of the BSDs have adopted it, but only midstream > (eg, its documented in OpenBSD 5.0, but not in 4.9). I looked in the autoconf manual: http://www.gnu.org/software/autoconf/manual/autoconf.html#grep "Portable scripts can rely on the grepoptions -c, -l, -n, and -v, but should avoid other options" ___ 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
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
[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 --- 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: Xwayland DDX: build breaks in configuration
On 14-04-03 07:54 PM, Gaetan Nadon wrote:
> 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')'
Looks like an external dependency was introduced: WAYLAND_SCANNER_RULES
macro
http://lists.freedesktop.org/archives/wayland-devel/2011-June/001156.html:
If wayland-scanner.m4 is missing, the WAYLAND_SCANNER_RULES macro is
undefined, and this token ends up in the generated configure script.
This makes autogen.sh (or autoreconf) succeed, but configure fail.
___
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
[PATCH util-macros 2/2] Use the new XORG_AUTHORS macro for the util-macros package
Signed-off-by: Gaetan Nadon --- .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
[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 --- 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
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
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 Reviewed-by: Gaetan Nadon ___ 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 > --- > configure.ac | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) Reviewed-by: Gaetan Nadon ___ 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 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 Reviewed-by: Gaetan Nadon 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 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 ___ 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 >>> --- >>> 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=19&t=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 xorg-docs] Fix typo in Release Notes.
Signed-off-by: Gaetan Nadon --- 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. - Xorg has currently has support for Linux, Solaris, + Xorg 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
[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 --- 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 xserver] suid: replace deprecated AC_HELP_STRING with AS_HELP_STRING
Fixes automake warning. Signed-off-by: Gaetan Nadon --- configure.ac |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index a75ba8f..f051414 100644 --- a/configure.ac +++ b/configure.ac @@ -624,8 +624,8 @@ AC_ARG_ENABLE(clientids, AS_HELP_STRING([--disable-clientids], [Build Xorg AC_ARG_ENABLE(pciaccess, AS_HELP_STRING([--enable-pciaccess], [Build Xorg with pciaccess library (default: enabled)]), [PCI=$enableval], [PCI=yes]) AC_ARG_ENABLE(linux_acpi, AS_HELP_STRING([--disable-linux-acpi], [Disable building ACPI support on Linux (if available).]), [enable_linux_acpi=$enableval], [enable_linux_acpi=yes]) AC_ARG_ENABLE(linux_apm, AS_HELP_STRING([--disable-linux-apm], [Disable building APM support on Linux (if available).]), [enable_linux_apm=$enableval], [enable_linux_apm=yes]) -AC_ARG_ENABLE(systemd-logind, AC_HELP_STRING([--enable-systemd-logind], [Build systemd-logind support (default: auto)]), [SYSTEMD_LOGIND=$enableval], [SYSTEMD_LOGIND=auto]) -AC_ARG_ENABLE(suid-wrapper, AC_HELP_STRING([--enable-suid-wrapper], [Build suid-root wrapper for legacy driver support on rootless xserver systems (default: no)]), [SUID_WRAPPER=$enableval], [SUID_WRAPPER=no]) +AC_ARG_ENABLE(systemd-logind, AS_HELP_STRING([--enable-systemd-logind], [Build systemd-logind support (default: auto)]), [SYSTEMD_LOGIND=$enableval], [SYSTEMD_LOGIND=auto]) +AC_ARG_ENABLE(suid-wrapper, AS_HELP_STRING([--enable-suid-wrapper], [Build suid-root wrapper for legacy driver support on rootless xserver systems (default: no)]), [SUID_WRAPPER=$enableval], [SUID_WRAPPER=no]) dnl DDXes. AC_ARG_ENABLE(xorg, AS_HELP_STRING([--enable-xorg], [Build Xorg server (default: auto)]), [XORG=$enableval], [XORG=auto]) -- 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] suid: add generated Xorg.sh to hw/xfree86/.gitignore
Signed-off-by: Gaetan Nadon --- hw/xfree86/.gitignore |1 + 1 file changed, 1 insertion(+) diff --git a/hw/xfree86/.gitignore b/hw/xfree86/.gitignore index 997a94e..fb6830b 100644 --- a/hw/xfree86/.gitignore +++ b/hw/xfree86/.gitignore @@ -1,4 +1,5 @@ Xorg +Xorg.sh xorg.conf.example sdksyms.c sdksyms.dep -- 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 xinit 1/3] Drop $RAWCPPFLAGS when generating startx
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
> ---
> 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?
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=19&t=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.
3. As for SCO, this OS is no longer supported, so we will never know.
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. Any
idea on what happens to other platforms and/or other non-gnu compilers?
The -undef flag was added in Sept 2005. Are you running into a problem?
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.
For reference, this is how RAWCPPFLAGS get populated from util/macros:
# Check for flag to avoid builtin definitions - assumes unix is
predefined,
# which is not the best choice for supporting other OS'es, but
covers most
# of the ones we need for now.
AC_MSG_CHECKING([if $RAWCPP requires -undef])
AC_LANG_CONFTEST([AC_LANG_SOURCE([[Does cpp redefine unix ?]])])
if test `${RAWCPP} < conftest.$ac_ext | grep -c 'unix'` -eq 1 ; then
AC_MSG_RESULT([no])
else
if test `${RAWCPP} -undef < conftest.$ac_ext | grep -c 'unix'`
-eq 1 ; then
RAWCPPFLAGS=-undef
AC_MSG_RESULT([yes])
# under Cygwin unix is still defined even with -undef
elif test `${RAWCPP} -undef -ansi < conftest.$ac_ext | grep -c
'unix'` -eq 1 ; then
RAWCPPFLAGS="-undef -ansi"
AC_MSG_RESULT([yes, with -ansi])
else
AC_MSG_ERROR([${RAWCPP} defines unix with or without
-undef. I don't know what to do.])
fi
fi
rm -f conftest.$ac_ext
AC_MSG_CHECKING([if $RAWCPP requires -traditional])
AC_LANG_CONFTEST([AC_LANG_SOURCE([[Does cpp preserve
"whitespace"?]])])
if test `${RAWCPP} < conftest.$ac_ext | grep -c 'preserve \"'` -eq
1 ; then
AC_MSG_RESULT([no])
else
if test `${RAWCPP} -traditional < conftest.$ac_ext | grep -c
'preserve \"'` -eq 1 ; then
RAWCPPFLAGS="${RAWCPPFLAGS} -traditional"
AC_MSG_RESULT([yes])
else
AC_MSG_ERROR([${RAWCPP} does not preserve whitespace with or
without -traditional. I don't know what to do.])
fi
fi
rm -f conftest.$ac_ext
AC_SUBST(RAWCPPFLAGS)
]) # XORG_PROG_RAWCPP
___
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 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 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: 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: 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: [PATCH xserver] xfree86: glamor_egl subdir must be distributed - breaks distcheck
On 14-03-21 04:53 PM, Eric Anholt wrote: > Gaetan Nadon writes: > >> Signed-off-by: Gaetan Nadon > 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
[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 --- 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 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
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
[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 --- 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 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
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 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 > Cc: Gaetan Nadon > --- > .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 ___ 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 --- 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
[PATCH xserver] ephyr: spurious $() in the Makefile breaks the make 'dist' target
Introduced in commit 9fe052d90cca90fdf750d3a45b151be2ac7f0ebd Signed-off-by: Gaetan Nadon --- 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
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
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 > --- > > 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 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: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 > --- > hash.c| 2 ++ > mkfontscale.c | 2 ++ > 2 files changed, 4 insertions(+) > Reviewed-by: Gaetan Nadon ___ 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 #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 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-24 05:27 PM, Keith Packard wrote: > Gaetan Nadon 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: [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 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-23 11:46 PM, Keith Packard wrote: > Gaetan Nadon 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: 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
[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 --- 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
[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 --- 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 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 >> >> 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
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 >>> >>> 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 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
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
[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 --- 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
[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 --- 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 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 --- 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 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 --- 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.
[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 --- 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/xfree
[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/bio
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
[PATCH xserver] config: fails to create tarball as xorg-server.conf file removed
Just need to update EXTRA_DIST Reviewed-by: Peter Hutterer Signed-off-by: Gaetan Nadon --- 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 Signed-off-by: Gaetan Nadon --- 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: [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
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-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: [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: [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: [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 > --- > 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: [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: [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 ___ 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-10 06:57 PM, Keith Packard wrote:
> Gaetan Nadon 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 flag
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-09 07:03 PM, Keith Packard wrote: > Gaetan Nadon 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-09 02:42 PM, Alan Coopersmith wrote: > On 02/ 9/14 11:12 AM, Keith Packard wrote: >> Gaetan Nadon 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: [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 05:55 AM, Keith Packard wrote: > Gaetan Nadon 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
[PATCH util-macros 2/2] Add XORG_WITH_M4 macro
From: Arnaud Fontaine 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 --- 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 2>&1 && \ + 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: [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 > --- > 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 ]) 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
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 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
