Bug 41033

Summary:	use dbus/dbus-arch-deps.h.in as source for CMake too
Product:	dbus	Reporter:	Simon McVittie <smcv>
Component:	core	Assignee:	Ralf Habacker <ralf.habacker>
Status:	RESOLVED FIXED	QA Contact:	John (J5) Palmieri <johnp>
Severity:	minor
Priority:	medium	CC:	hp, ralf.habacker, smcv
Version:	1.5	Keywords:	patch
Hardware:	All
OS:	All
Whiteboard:
i915 platform:		i915 features:
Bug Depends on:	40905
Bug Blocks:
Attachments:	use dbus/dbus-arch-deps.h.in as source for CMake too

Description Simon McVittie 2011-09-20 04:16:32 UTC

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

Comment 1 Ralf Habacker 2011-09-22 13:39:45 UTC

Created attachment 51529 [details] [review]
use dbus/dbus-arch-deps.h.in as source for CMake too

Comment 2 Simon McVittie 2011-09-23 03:12:38 UTC

(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.

Comment 3 Ralf Habacker 2011-09-23 06:40:25 UTC

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 :-)

Comment 4 Ralf Habacker 2011-09-23 07:29:49 UTC

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

Comment 5 Simon McVittie 2011-09-23 07:45:54 UTC

(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.

Comment 6 Ralf Habacker 2011-09-23 08:23:11 UTC

(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

Comment 7 Ralf Habacker 2011-09-25 23:17:33 UTC

> 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.