[RFC] Detect system XKB installation paths
Yaakov (Cygwin/X)
yselkowitz at users.sourceforge.net
Wed Mar 24 11:42:02 PDT 2010
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
More information about the xorg-devel
mailing list