dbus/dbus-arch-deps.h.in and cmake/dbus/dbus-arch-deps.h.cmake are remarkably similar, and all the differences between them look to me like bugs (or at least limitations) in the cmake version. It'd be better to have a single source file used by both build systems. This would mean avoiding use of #cmakedefine and just using @THING@ substitutions, which both build systems can do. Differences between the two: * In the cmake version, DBUS_BEGIN_DECLS and DBUS_END_DECLS have an unnecessary trailing semicolon * In the cmake version, uses of _DBUS_GNUC_EXTENSION are missing, which would cause extra warnings with gcc -pedantic * The cmake version uses #cmakedefine to check DBUS_HAVE_INT64, which will break "fat binaries" on Mac OS X: it should use "#if @DBUS_HAVE_INT64@" and define DBUS_HAVE_INT64 to 1 or 0 * The autoconf version uses @DBUS_INT64_CONSTANT@ and @DBUS_UINT64_CONSTANT@ whereas the cmake version implicitly assumes that int64 is "long long"; the checks in ConfigureChecks.cmake should define DBUS_INT64_CONSTANT and DBUS_UINT64_CONSTANT to the same things configure.ac produces (chosen from (val), (val##L), (val##LL), (val##i64) according to whether int64 is int, long, long long or __int64, with a U, U, U or u added for the unsigned version) * Bug #40905, but Ralf has fixed that already
Created attachment 51529 [details] [review] use dbus/dbus-arch-deps.h.in as source for CMake too
(In reply to comment #1) > Created an attachment (id=51529) [details] > use dbus/dbus-arch-deps.h.in as source for CMake too You're missing DBUS_[U]INT64_CONSTANT definitions for the "int is 8 bytes" case: set (DBUS_INT64_CONSTANT "(val)") set (DBUS_UINT64_CONSTANT "(val##U)") (although no current platform has 8-byte ints, and they were broken in configure.ac for a long time too...) With that fixed, this would be ideal; the "elseif" construction is a lot nicer than deeply-nested ifs.
fixed (In reply to comment #2) > With that fixed, this would be ideal; fixed and committed > the "elseif" construction is a lot nicer than deeply-nested ifs. yes :-)
BTW: Simon, there are a more .cmake config files which could be merged back into the related *.in files. I'm refering to session.conf.cmake, system.conf.cmake and service.cmake
(In reply to comment #4) > BTW: Simon, there are a more .cmake config files which could be merged back > into the related *.in files. I'm refering to session.conf.cmake, > system.conf.cmake and service.cmake I have a branch to improve the tests infrastructure which does quite a lot of this; I'll cc you on the bug when it's ready for review.
(In reply to comment #5) > I have a branch to improve the tests infrastructure which does quite a lot of > this; I'll cc you on the bug when it's ready for review. Nice to hear :-) In my dbus work pipeline there are also two windows related patches 1. client config file support http://lists.freedesktop.org/archives/dbus/2010-June/012914.html 2. exclude selinux on windows https://bugs.freedesktop.org/show_bug.cgi?id=32407
> I have a branch to improve the tests infrastructure which does quite a lot of > this; I'll cc you on the bug when it's ready for review. When will this happens ?
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.