The problem seems to be a race condition with winsock's
internal threads for the non-blocking mode of the sockets,
but I haven't had time to try a standalone test case yet
to confirm it. Anyway, I found a workaround that fixes it
in all cases, so it's good enough for now.
This uploads a doc tarball, and its contents, to the appropriate
location on dbus.freedesktop.org. It also uploads the DTDs to the
appropriate location on specifications.freedesktop.org.
I believe this uploads the same files as the old update-dbus-docs.sh
script did.
Previously the configure output always said these were enabled during
the 'Checking for...' stage, even if they weren't. The summary at the
end of configure was correct, though.
This will make integrating the building of HTML versions of these
manpages into the build system way easier, at the cost of keeping
manpages in a different directory to the source for the program they
describe. I think this is an acceptable trade-off.
This depends on GNU Make for the wildcard dependency on all the source
files in dbus/. If anyone objects very strongly to this, I'd welcome
suggestions of a more portable way to do this.
Automake 1.11 adds support for silent rules, which are conditionally
enabled in configure.in if available.
Also, previously it was impossible to override the version chosen by
this script; this patch makes that possible.
A Red Hat QA engineer hit in practice a race condition in dbus-uuidgen
where it could leave an empty file.
dbus-uuidgen (_dbus_create_uuid_file_exclusively) formerly created an
empty file in the path to the uuid, then filled it in. At some point,
the internal libdbus _dbus_string_save_to_file became atomic on Unix
at least (doing the save to temp file, fsync(), rename() dance).
So _dbus_create_uuid_file_exclusively doesn't need to create the file
beforehand anymore. However, it *does* need the file to be
world-readable, unlike all other consumers of
_dbus_string_save_to_file. So add a "world_readable" argument.
