Patch to not fork/exec xkbcomp on X Server initialization

[Paulo Cesar Pereira de Andrade]

Daniel Stone wrote:
>> A rewrite may be a better option, but is there any reason we can't put
>> paulo's patch into master for the time being? Worse comes to worst it's
>> reverted (or removed) when the rewrite happens. Trying to debug xkb startup is
>> a pain right now, and removing the fork may just convince my gdb not to die
>> the death of a thousand sins.
>
> The thing is that this still forks, so you're still screwed on startup,
> and you still have the XKM mess.  All it does is cache the output
> somewhere.

  I am attaching a more complete patch. Now it creates a SHA1 of the
contents of the .tmp file. It still creates a temporary file because
the functions require outputing to a file. This could be reworked to
avoid "using the filesystem" to send parameters from one function
to another; just not added to this patch because almost everything
is a fprintf and not so trivial to wrap to using a temp buffer.

  It also requires snprintf, openssl and linking the X Server with -lcrypto.
This is a prototype patch, and for server-1.4-branch...

>> and the thing with rewrites is that they tend to always take longer than
>> expected, so if there's an interim solution I'm not the one to complain.
>
> Yeah, I'm still happy to try the smashing-xkbcomp-in-its-current-form-in
> thing again.
>
> Cheers,
> Daniel

Paulo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Don-t-fork-exec-xkbcomp-if-a-cache-file-exists.patch
Type: text/x-patch
Size: 22653 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20080702/fba9c06b/attachment.bin>