Re: [RFC] Detect system XKB installation paths
On 2010-03-23 08:29, Dan Nicholson wrote: I've wanted to do this for a while, but there are a couple issues. FWIW, I'm trying to keep in mind several different scenarios: 1) where xserver is being built to update an existing version with the same prefix, e.g. by distributors. This patch shouldn't change anything in that case. 2) where only xserver is built against system-installed dependencies but with a separate prefix, e.g. from git where no arguments are passed to autogen.sh (which then defaults to /usr/local vs. the system /usr). Without something like this, the server builds but fails to run because it expects these packages in its prefix. 3) where a complete X.Org system is built in a separate prefix from the system-installed version, such as jhbuild. Within jhbuild we could certainly add xkeyboard-config and xkbcomp as dependencies of xserver (if they are not already) without creating a hard dep for other scenarios. 4) where X.Org is being cross-compiled, we need to be sure not to pick up the build system's installation. Why exclude cross compiling? Using PKG_CHECK_EXISTS or AC_PATH_PROG have no problems in those situations. My concern was (4) above. I'm not that familiar with cross-compiling; it makes sense that the pkg-config call should work, but wouldn't AC_PATH_PROG be prone to pick up the build system's xkbconf? Check if DEFAULT_XKB_PATH is empty and set it to ${datadir}/X11/xkb if so. Then we can fallback gracefully on older xkeyboard-config installations. In what case would DEFAULT_XKB_PATH be empty? The PKG_CHECK_EXISTS will do nothing if the .pc file is not present (meaning that either xkeyboard-config is not installed or it is an older version w/o that file). The only drawback is that there's never been a hard requirement on having xkeyboard-config installed before xserver, and we risk picking up the host's installation instead of the one the user expects. Still the CHECKING/RESULT is nice and informs people. This does not add a *hard* dep on xkeyboard-config at configure time; if xkeyboard-config.pc is not present, you end up with $datadir/X11/xkb just as before. Adding a dep within the scope of jhbuild would fix that case but should not be necessary for other scenarios. Same argument as above where we're likely to pick up the host's xkbcomp since there was no hard requirement before. Hopefully they'd see the result in the output. Which is why I didn't want to do this if cross-compiling. Besides that and jhbuild (easily fixable), how else might this break things? We should remove this stupid macro and just #define the path to xkbcomp until some glorious future where it doesn't need to be forked from the server. That's a separate patch, but --with-xkbcomp would be better. That would require a more extensive patch affecting at least three .c files in xkb/. Yaakov Cygwin/X ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Detect system XKB installation paths
On Wed, Mar 24, 2010 at 11:42 AM, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: On 2010-03-23 08:29, Dan Nicholson wrote: I've wanted to do this for a while, but there are a couple issues. FWIW, I'm trying to keep in mind several different scenarios: 1) where xserver is being built to update an existing version with the same prefix, e.g. by distributors. This patch shouldn't change anything in that case. Agreed. 2) where only xserver is built against system-installed dependencies but with a separate prefix, e.g. from git where no arguments are passed to autogen.sh (which then defaults to /usr/local vs. the system /usr). Without something like this, the server builds but fails to run because it expects these packages in its prefix. Yeah, this is the one I've always wanted to fix. This is a spot where xkb is a little special, though. You _can_ get the xserver to use your system xkb files, but trying to use the system xkbcomp with local xkb files can be problematic due to xkbcomp's handling of paths. This is why symlink to your host's xkbcomp in $xprefix/bin is not actually a useful suggestion. But that's a little orthogonal to this patch. 3) where a complete X.Org system is built in a separate prefix from the system-installed version, such as jhbuild. Within jhbuild we could certainly add xkeyboard-config and xkbcomp as dependencies of xserver (if they are not already) without creating a hard dep for other scenarios. If this patch lands, we would most certainly want to make them deps of the xserver in jhbuild and build.sh. 4) where X.Org is being cross-compiled, we need to be sure not to pick up the build system's installation. Why exclude cross compiling? Using PKG_CHECK_EXISTS or AC_PATH_PROG have no problems in those situations. My concern was (4) above. I'm not that familiar with cross-compiling; it makes sense that the pkg-config call should work, but wouldn't AC_PATH_PROG be prone to pick up the build system's xkbconf? No more than situations 1-3 above, but I suppose that's the reason AC_CHECK_FILE bails on cross compiling. Since we're actually encoding runtime dependencies, I think we'd want to pick up the tools in the cross prefix. Maybe it's safer to default to paths under $prefix in that case. Let's leave it your way until someone that this actually affects complains. Check if DEFAULT_XKB_PATH is empty and set it to ${datadir}/X11/xkb if so. Then we can fallback gracefully on older xkeyboard-config installations. In what case would DEFAULT_XKB_PATH be empty? The PKG_CHECK_EXISTS will do nothing if the .pc file is not present (meaning that either xkeyboard-config is not installed or it is an older version w/o that file). Ah, right. There isn't an existing version of xkeyboard-config.pc that doesn't have xkb_base variable. Probably fine. The only drawback is that there's never been a hard requirement on having xkeyboard-config installed before xserver, and we risk picking up the host's installation instead of the one the user expects. Still the CHECKING/RESULT is nice and informs people. This does not add a *hard* dep on xkeyboard-config at configure time; if xkeyboard-config.pc is not present, you end up with $datadir/X11/xkb just as before. Adding a dep within the scope of jhbuild would fix that case but should not be necessary for other scenarios. Sooner or later, though, we'll have system copies of xkeyboard-config.pc, which means you'll get /usr/share/X11/xkb when you might not have expected it. I think that's OK, but we need to fix the build tools and make sure people know about it. Same argument as above where we're likely to pick up the host's xkbcomp since there was no hard requirement before. Hopefully they'd see the result in the output. Which is why I didn't want to do this if cross-compiling. Besides that and jhbuild (easily fixable), how else might this break things? Cases 2 and 3 above. Things can get broken trying to mix your system xkbcomp (with builtin path /usr/share/X11/xkb) and local xkb files. I think we just have to make sure people understand this change. I just wanted to note the drawback of it. We should remove this stupid macro and just #define the path to xkbcomp until some glorious future where it doesn't need to be forked from the server. That's a separate patch, but --with-xkbcomp would be better. That would require a more extensive patch affecting at least three .c files in xkb/. Yep, some other day unless Daniel lands xkb2 and nukes xkbcomp from orbit. -- Dan ___ 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
[RFC] Detect system XKB installation paths
From: Yaakov Selkowitz yselkow...@users.sourceforge.net In the case where xserver is built in a different prefix from xkbcomp and xkeyboard-config, e.g. when building from git with autogen.sh without arguments (which defaults to /usr/local) against distro-installed components (usually in /usr), assuming the same prefix will cause the server to not find these and fail to run. Instead, if not cross-compiling, detect the system-installed locations if present and use these instead. Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net --- This depends on my newly-proposed patch for xkeyboard-config: https://bugs.freedesktop.org/show_bug.cgi?id=27257 Therefore this is *not* intended as a candidate for xserver 1.8. configure.ac | 25 ++--- 1 files changed, 22 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index e9f9453..55e9156 100644 --- a/configure.ac +++ b/configure.ac @@ -523,9 +523,19 @@ AC_ARG_WITH(default-font-path, AS_HELP_STRING([--with-default-font-path=PATH], [ AC_MSG_CHECKING([for default font path]) AC_MSG_RESULT([$FONTPATH]) -AC_ARG_WITH(xkb-path, AS_HELP_STRING([--with-xkb-path=PATH], [Path to XKB base dir (default: ${datadir}/X11/xkb)]), +DEFAULT_XKB_PATH=${datadir}/X11/xkb +if test $cross_compiling != yes; then + PKG_CHECK_EXISTS(xkeyboard-config, + [DEFAULT_XKB_PATH=`$PKG_CONFIG --variable=xkb_base xkeyboard-config`]) +fi + +AC_ARG_WITH(xkb-path, AS_HELP_STRING([--with-xkb-path=PATH], [Path to XKB base dir (default: auto)]), [ XKBPATH=$withval ], - [ XKBPATH=${datadir}/X11/xkb ]) + [ XKBPATH=${DEFAULT_XKB_PATH} ]) + +AC_MSG_CHECKING([for XKB data directory]) +AC_MSG_RESULT([$XKBPATH]) + AC_ARG_WITH(xkb-output, AS_HELP_STRING([--with-xkb-output=PATH], [Path to XKB output dir (default: ${datadir}/X11/xkb/compiled)]), [ XKBOUTPUT=$withval ], [ XKBOUTPUT=compiled ]) @@ -1135,10 +1145,19 @@ AM_CONDITIONAL(INT10MODULE, test x$INT10MODULE = xyes) AC_DEFINE(SHAPE, 1, [Support SHAPE extension]) AC_DEFINE_DIR(XKB_BASE_DIRECTORY, XKBPATH, [Path to XKB data]) + +DEFAULT_XKB_BIN_DIR=${bindir} +if test $cross_compiling != yes; then + AC_PATH_PROG(XKBCOMP, xkbcomp) + if test $XKBCOMP != ; then + DEFAULT_XKB_BIN_DIR=`dirname $XKBCOMP` + fi +fi + AC_ARG_WITH(xkb-bin-directory, AS_HELP_STRING([--with-xkb-bin-directory=DIR], [Directory containing xkbcomp program]), [XKB_BIN_DIRECTORY=$withval], - [XKB_BIN_DIRECTORY=$bindir]) + [XKB_BIN_DIRECTORY=${DEFAULT_XKB_BIN_DIR}]) AC_DEFINE_DIR(XKB_BIN_DIRECTORY, XKB_BIN_DIRECTORY, [Path to XKB bin dir]) -- 1.6.6.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: [RFC] Detect system XKB installation paths
On Tue, Mar 23, 2010 at 3:22 AM, Yaakov (Cygwin/X) yselkow...@users.sourceforge.net wrote: From: Yaakov Selkowitz yselkow...@users.sourceforge.net In the case where xserver is built in a different prefix from xkbcomp and xkeyboard-config, e.g. when building from git with autogen.sh without arguments (which defaults to /usr/local) against distro-installed components (usually in /usr), assuming the same prefix will cause the server to not find these and fail to run. Instead, if not cross-compiling, detect the system-installed locations if present and use these instead. Signed-off-by: Yaakov Selkowitz yselkow...@users.sourceforge.net I've wanted to do this for a while, but there are a couple issues. --- This depends on my newly-proposed patch for xkeyboard-config: https://bugs.freedesktop.org/show_bug.cgi?id=27257 Therefore this is *not* intended as a candidate for xserver 1.8. configure.ac | 25 ++--- 1 files changed, 22 insertions(+), 3 deletions(-) diff --git a/configure.ac b/configure.ac index e9f9453..55e9156 100644 --- a/configure.ac +++ b/configure.ac @@ -523,9 +523,19 @@ AC_ARG_WITH(default-font-path, AS_HELP_STRING([--with-default-font-path=PATH], [ AC_MSG_CHECKING([for default font path]) AC_MSG_RESULT([$FONTPATH]) -AC_ARG_WITH(xkb-path, AS_HELP_STRING([--with-xkb-path=PATH], [Path to XKB base dir (default: ${datadir}/X11/xkb)]), +DEFAULT_XKB_PATH=${datadir}/X11/xkb +if test $cross_compiling != yes; then Why exclude cross compiling? Using PKG_CHECK_EXISTS or AC_PATH_PROG have no problems in those situations. + PKG_CHECK_EXISTS(xkeyboard-config, + [DEFAULT_XKB_PATH=`$PKG_CONFIG --variable=xkb_base xkeyboard-config`]) Check if DEFAULT_XKB_PATH is empty and set it to ${datadir}/X11/xkb if so. Then we can fallback gracefully on older xkeyboard-config installations. +fi + +AC_ARG_WITH(xkb-path, AS_HELP_STRING([--with-xkb-path=PATH], [Path to XKB base dir (default: auto)]), [ XKBPATH=$withval ], - [ XKBPATH=${datadir}/X11/xkb ]) + [ XKBPATH=${DEFAULT_XKB_PATH} ]) + +AC_MSG_CHECKING([for XKB data directory]) +AC_MSG_RESULT([$XKBPATH]) The only drawback is that there's never been a hard requirement on having xkeyboard-config installed before xserver, and we risk picking up the host's installation instead of the one the user expects. Still the CHECKING/RESULT is nice and informs people. + AC_ARG_WITH(xkb-output, AS_HELP_STRING([--with-xkb-output=PATH], [Path to XKB output dir (default: ${datadir}/X11/xkb/compiled)]), [ XKBOUTPUT=$withval ], [ XKBOUTPUT=compiled ]) @@ -1135,10 +1145,19 @@ AM_CONDITIONAL(INT10MODULE, test x$INT10MODULE = xyes) AC_DEFINE(SHAPE, 1, [Support SHAPE extension]) AC_DEFINE_DIR(XKB_BASE_DIRECTORY, XKBPATH, [Path to XKB data]) + +DEFAULT_XKB_BIN_DIR=${bindir} +if test $cross_compiling != yes; then + AC_PATH_PROG(XKBCOMP, xkbcomp) + if test $XKBCOMP != ; then + DEFAULT_XKB_BIN_DIR=`dirname $XKBCOMP` + fi +fi Same argument as above where we're likely to pick up the host's xkbcomp since there was no hard requirement before. Hopefully they'd see the result in the output. + AC_ARG_WITH(xkb-bin-directory, AS_HELP_STRING([--with-xkb-bin-directory=DIR], [Directory containing xkbcomp program]), [XKB_BIN_DIRECTORY=$withval], - [XKB_BIN_DIRECTORY=$bindir]) + [XKB_BIN_DIRECTORY=${DEFAULT_XKB_BIN_DIR}]) AC_DEFINE_DIR(XKB_BIN_DIRECTORY, XKB_BIN_DIRECTORY, [Path to XKB bin dir]) We should remove this stupid macro and just #define the path to xkbcomp until some glorious future where it doesn't need to be forked from the server. That's a separate patch, but --with-xkbcomp would be better. -- Dan ___ 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