[PATCH app/xkbcomp] Add xkboutputdir to xkbcomp.pc

[Peter Hutterer]

On Thu, Mar 09, 2017 at 11:08:16AM +0000, Daniel Stone wrote:
> Hi,
> 
> On 9 March 2017 at 04:56, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > On Wed, Mar 08, 2017 at 11:51:20AM -0500, Adam Jackson wrote:
> >> On Wed, 2017-03-08 at 13:45 +0000, Emil Velikov wrote:
> >> > Right, so I was confused. The "compiled" xkb path and README.compiled
> >> > are provided by Xorg, but what's not obvious is - who is the user of
> >> > said path/files ?
> >> > This patch on its own does not make much sense, I'm afraid - we add a
> >> > "default" location and we have nobody of change and/or read it :-\
> >>
> >> I would like to read these values from xserver's configure.ac, among
> >> other reasons so we can drop the DISTCHECK_CONFIGURE_FLAGS nonsense in
> >> its Makefile.am. But I can't do that until and unless xkbcomp.pc
> >> actually _has_ this information.
> >
> > The thing is though that this isn't something that has anything to do with
> > xkbcomp, we literally call "xkbcomp [...] /foo/bar/mykeymap.xkm" and expect
> > the output to be written there. xkbcomp doesn't care where as long as it can
> > write that file. This should be in /var/run/$pid/ and we should default to
> > that in configure, although there's some argument to keeping them across
> > server restarts.
> >
> > Does anything else actually rely on that path? because if it's just for the
> > distcheck flags, I don't think this is worth it.
> 
> My thoughts exactly. Nothing relies on it other than the server, which
> needs to know that it has a place it can write files reliably and
> securely whilst suid. That could probably be eliminated by just
> calling mkdtemp to do the path every time. (And hey, whilst you're
> there, why not eliminate the xkbcomp fork/exec entirely and save
> yourself a pile of startup time. Ha ha.)

don't we already do this by compiling and caching the lot? so in theory we
only fork once per different keymap which in most cases is... once :)

Cheers,
  Peter