[PATCH libXt] Install ErrorDB into a $datarootdir-path, not $libdir.

Egbert Eich eich at freedesktop.org
Thu Sep 8 00:38:06 PDT 2011

On Wed, Sep 07, 2011 at 09:01:13PM -0400, Gaetan Nadon wrote:
> On Wed, 2011-09-07 at 21:03 +0000, Egbert Eich wrote:
> > > 
> > > If there is a need for a module to get at the XtErrorDB path, I would
> > > suggest an explicit variable name. One should be able to figure it out
> > > simply by looking at the pc file.
> > 
> > 
> > Ok, this is a valid point. Like in libXcursor it should be:
> > datarootdir=@datarootdir@
> > ...
> > errordbdir=${datarootdir}
> > 
> > or just:
> > 
> > errordbdir=@datarootdir@
> libXcursor is a good example. The ICONDIR is defined is one location,
> configure.ac, and made available to both the makefile and the pc file.
> If the value is changed, both are in sync. Note that the statement
> ICONDIR=@ICONDIR@ in the makefile is redundant.
> The way it is for libXt in the patch has a loophole. The value for
> errordbdir is defined separately in two locations. If the value is
> changed in the makefile, there is a high risk of not being changed in
> the pc file.

The difference though is that ICONDIR is separately configurable at
build time. There is no plan to ever do this for the errordbdir.

If we wanted to have a single place to configure this we'd have to
add it to configure.ac:



errordb = @ERRORDBDIR@

(I've replaced datarootdir by datadir).
If you don't feel that this is a bit overkill I will do that.

> > This is in case a '3rd party' wants to supply this file. All this 
> > is pretty much overkill anyway as I don't expect this to happen ever.
> There is always the option of waiting for a requirement to implement
> this feature. Now that you mention this feature has never existed
> before, it should be in a separate patch. It would be easier to locate
> when reading the change log.

It is not likely that this will ever happen. Xt is old X11 legacy
superseded by modern toolkits. It is still badly needed, though
as it is used in Motif, a widget toolkit that's still used heavily
for many long exisiting (business) applications. It doesn't meet
modern requirements among other things it's i18n support doesn't
provide what's needed today.

> Thanks, and sorry for the extra work.

NP. If we can agree on how to do it I will happlily provide the


More information about the xorg-devel mailing list