Bug 43639 - --with-dbus-transport option for autoconf
Summary: --with-dbus-transport option for autoconf
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: unspecified
Hardware: Other Windows (All)
: medium enhancement
Assignee: Havoc Pennington
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-12-08 11:44 UTC by Siraj Razick
Modified: 2013-05-10 17:12 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Patch to add --with-dbus-transport option (1.29 KB, patch)
2011-12-08 11:50 UTC, Siraj Razick
Details | Splinter Review
Patch to set the default session bus address on windows using ---with-dbus-session-bus-default-address open (1.83 KB, patch)
2011-12-21 10:29 UTC, Siraj Razick
Details | Splinter Review

Description Siraj Razick 2011-12-08 11:44:39 UTC
when using autotools to cross compile or build on winodows, the transport is hardcoded as nonce-tcp always. to change it we need to change configure.ac at build time or change the session.conf by hand later. 

in the cmake buildsystem there is one option to set the transport that should be used, which is missing in auto tools.

So this bug is to propose a configure time option to define the transport that should be used on windows.

The default value will be nonce-tcp if the user does not specify this at build time.
Comment 1 Siraj Razick 2011-12-08 11:50:01 UTC
Created attachment 54250 [details] [review]
Patch to add --with-dbus-transport option

Patch witch adds configure time option to define the dbus transport to be used in windows
Comment 2 Simon McVittie 2011-12-09 03:04:11 UTC
(In reply to comment #0)
> when using autotools to cross compile or build on winodows, the transport is
> hardcoded as nonce-tcp always. to change it we need to change configure.ac at
> build time or change the session.conf by hand later.

... and on Unix, the default transport is hard-coded to be unix:. That's because Unix sockets are obviously the best choice for the standard session bus on Unix, and everything else is sufficiently clearly worse that it shouldn't be changed without a very good reason.

If nonce-tcp has a similar position as "clearly the best choice" on Windows, then it seems reasonable to assume it. (I'm not completely clear on how the nonce-tcp transport works. Ralf, is it "obviously better than anything else"?)

From what you said on IRC it sounds as though your actual problem is "nonce-tcp is the default but doesn't work", which suggests that a better solution would be to fix it so it *does* work...
Comment 3 Simon McVittie 2011-12-09 03:04:43 UTC
(In reply to comment #2)
> If nonce-tcp has a similar position as "clearly the best choice" on Windows,
> then it seems reasonable to assume it. (I'm not completely clear on how the
> nonce-tcp transport works. Ralf, is it "obviously better than anything else"?)

... if I'm going to ask Ralf questions it would help if I cc'd him.
Comment 4 Siraj Razick 2011-12-09 08:54:03 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > when using autotools to cross compile or build on winodows, the transport is
> > hardcoded as nonce-tcp always. to change it we need to change configure.ac at
> > build time or change the session.conf by hand later.
> 
> ... and on Unix, the default transport is hard-coded to be unix:. That's
> because Unix sockets are obviously the best choice for the standard session bus
> on Unix, and everything else is sufficiently clearly worse that it shouldn't be
> changed without a very good reason.
> 
> If nonce-tcp has a similar position as "clearly the best choice" on Windows,
> then it seems reasonable to assume it. (I'm not completely clear on how the
> nonce-tcp transport works. Ralf, is it "obviously better than anything else"?)
> 
> From what you said on IRC it sounds as though your actual problem is "nonce-tcp
> is the default but doesn't work", which suggests that a better solution would
> be to fix it so it *does* work...

Yeah pretty much agree with this, We need to be sure that nonce-tcp works perfectly well. but currently it doesn't just work out of the box, compared to
other transports like autoluanch and tcp. I guess it's probably worth filing a new bug for this. 

In the mean time, I noticed that
cmake allows us to define this at compile time, but autotools' doesn't, and
big projects like KDE still uses autolaunch and I have seen many other people who do custom builds use tcp, i guess not having it is fine for individual or personal projects, but not when we build binaries which will be distributed, So this is the main reason I proposed this feature.
Comment 5 Ralf Habacker 2011-12-09 14:06:26 UTC
(In reply to comment #2)
> (In reply to comment #0)
> > when using autotools to cross compile or build on winodows, the transport is
> > hardcoded as nonce-tcp always. to change it we need to change configure.ac at
> > build time or change the session.conf by hand later.
> 
> ... and on Unix, the default transport is hard-coded to be unix:. That's
> because Unix sockets are obviously the best choice for the standard session bus
> on Unix, and everything else is sufficiently clearly worse that it 
> shouldn't be changed without a very good reason.
> 
> If nonce-tcp has a similar position as "clearly the best choice" on Windows,
> then it seems reasonable to assume it. (I'm not completely clear on how the
> nonce-tcp transport works. 

see http://dbus.freedesktop.org/doc/dbus-specification.html#transports-nonce-tcp-sockets

> Ralf, is it "obviously better than anything else"?)

> From what you said on IRC it sounds as though your actual problem is "nonce-tcp
> is the default but doesn't work", which suggests that a better solution would
> be to fix it so it *does* work...

Initial the cmake build system used tcp transport. When Frank Osterfeld from KDAB contributed the nonce-tcp implementation nonce-tcp has been set as default because it was better then raw tcp transport 
patch http://cgit.freedesktop.org/dbus/dbus/commit/cmake/CMakeLists.txt?id=5e2a99c12c7e3531d908ed4fca82caca9cb02825. 

Later I extended the autolaunch support http://dbus.freedesktop.org/doc/dbus-specification.html#meta-transports-autolaunch to be able to solve the needs of the KDE on windows project. 

It has been mentioned already: autolaunch is the default for the KDE on windows project in all variants.

It is the best choice in term of usability yet and I already thought about changing the default to autolaunch but on the other side noone has done a security check of the implementation.
Comment 6 Ralf Habacker 2011-12-09 14:16:10 UTC
(In reply to comment #4)
> (In reply to comment #2)
> > (In reply to comment #0)
> > > when using autotools to cross compile or build on winodows, the transport is
> > > hardcoded as nonce-tcp always. to change it we need to change configure.ac at
> > > build time or change the session.conf by hand later.
> > 
> > ... and on Unix, the default transport is hard-coded to be unix:. That's
> > because Unix sockets are obviously the best choice for the standard session bus
> > on Unix, and everything else is sufficiently clearly worse that it shouldn't be
> > changed without a very good reason.
> > 
> > If nonce-tcp has a similar position as "clearly the best choice" on Windows,
> > then it seems reasonable to assume it. (I'm not completely clear on how the
> > nonce-tcp transport works. Ralf, is it "obviously better than anything else"?)
> > 
> > From what you said on IRC it sounds as though your actual problem is "nonce-tcp
> > is the default but doesn't work", which suggests that a better solution would
> > be to fix it so it *does* work...
> 
> Yeah pretty much agree with this, We need to be sure that nonce-tcp works
> perfectly well. but currently it doesn't just work out of the box, compared to
> other transports like autoluanch and tcp. I guess it's probably worth filing a
> new bug for this. 
> 
> In the mean time, I noticed that
> cmake allows us to define this at compile time, but autotools' doesn't, and
> big projects like KDE still uses autolaunch and I have seen many other people
> who do custom builds use tcp, i guess not having it is fine for individual or
> personal projects, but not when we build binaries which will be distributed, So
> this is the main reason I proposed this feature.

In the cmake build system DBUS_SESSION_BUS_DEFAULT_ADDRESS could be used to set custom compile time default session transport. 

cmake ... -DDBUS_SESSION_BUS_DEFAULT_ADDRESS=...

Does autoconf do not have a similar switch ?
Comment 7 Siraj Razick 2011-12-09 14:26:49 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > (In reply to comment #2)
> > > (In reply to comment #0)
> > > > when using autotools to cross compile or build on winodows, the transport is
> > > > hardcoded as nonce-tcp always. to change it we need to change configure.ac at
> > > > build time or change the session.conf by hand later.
> > > 
> > > ... and on Unix, the default transport is hard-coded to be unix:. That's
> > > because Unix sockets are obviously the best choice for the standard session bus
> > > on Unix, and everything else is sufficiently clearly worse that it shouldn't be
> > > changed without a very good reason.
> > > 
> > > If nonce-tcp has a similar position as "clearly the best choice" on Windows,
> > > then it seems reasonable to assume it. (I'm not completely clear on how the
> > > nonce-tcp transport works. Ralf, is it "obviously better than anything else"?)
> > > 
> > > From what you said on IRC it sounds as though your actual problem is "nonce-tcp
> > > is the default but doesn't work", which suggests that a better solution would
> > > be to fix it so it *does* work...
> > 
> > Yeah pretty much agree with this, We need to be sure that nonce-tcp works
> > perfectly well. but currently it doesn't just work out of the box, compared to
> > other transports like autoluanch and tcp. I guess it's probably worth filing a
> > new bug for this. 
> > 
> > In the mean time, I noticed that
> > cmake allows us to define this at compile time, but autotools' doesn't, and
> > big projects like KDE still uses autolaunch and I have seen many other people
> > who do custom builds use tcp, i guess not having it is fine for individual or
> > personal projects, but not when we build binaries which will be distributed, So
> > this is the main reason I proposed this feature.
> 
> In the cmake build system DBUS_SESSION_BUS_DEFAULT_ADDRESS could be used to set
> custom compile time default session transport. 
> 
> cmake ... -DDBUS_SESSION_BUS_DEFAULT_ADDRESS=...
> 
> Does autoconf do not have a similar switch ?

Hi Ralf, 

Thanks for the response, at the moment it does not.. that's what I"m proposing with the patch and this bug.
Comment 8 Ralf Habacker 2011-12-09 14:41:17 UTC
(In reply to comment #7)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > (In reply to comment #2)
> > > > (In reply to comment #0)
> > > > > when using autotools to cross compile or build on winodows, the transport is
> > > > > hardcoded as nonce-tcp always. to change it we need to change configure.ac at
> > > > > build time or change the session.conf by hand later.
> > > > 
> > > > ... and on Unix, the default transport is hard-coded to be unix:. That's
> > > > because Unix sockets are obviously the best choice for the standard session bus
> > > > on Unix, and everything else is sufficiently clearly worse that it shouldn't be
> > > > changed without a very good reason.
> > > > 
> > > > If nonce-tcp has a similar position as "clearly the best choice" on Windows,
> > > > then it seems reasonable to assume it. (I'm not completely clear on how the
> > > > nonce-tcp transport works. Ralf, is it "obviously better than anything else"?)
> > > > 
> > > > From what you said on IRC it sounds as though your actual problem is "nonce-tcp
> > > > is the default but doesn't work", which suggests that a better solution would
> > > > be to fix it so it *does* work...
> > > 
> > > Yeah pretty much agree with this, We need to be sure that nonce-tcp works
> > > perfectly well. but currently it doesn't just work out of the box, compared to
> > > other transports like autoluanch and tcp. I guess it's probably worth filing a
> > > new bug for this. 
> > > 
> > > In the mean time, I noticed that
> > > cmake allows us to define this at compile time, but autotools' doesn't, and
> > > big projects like KDE still uses autolaunch and I have seen many other people
> > > who do custom builds use tcp, i guess not having it is fine for individual or
> > > personal projects, but not when we build binaries which will be distributed, So
> > > this is the main reason I proposed this feature.
> > 
> > In the cmake build system DBUS_SESSION_BUS_DEFAULT_ADDRESS could be used to set
> > custom compile time default session transport. 
> > 
> > cmake ... -DDBUS_SESSION_BUS_DEFAULT_ADDRESS=...
> > 
> > Does autoconf do not have a similar switch ?
> 
> Hi Ralf, 
> 
> Thanks for the response, at the moment it does not.. that's what I"m proposing
> with the patch and this bug.

Because DBUS_SESSION_BUS_DEFAULT_ADDRESS is already used would it then not make more sense to use DBUS_SESSION_BUS_DEFAULT_ADDRESS for autoconf too instead introducing a different switch ?
Comment 9 Ralf Habacker 2011-12-21 03:35:36 UTC
> Because DBUS_SESSION_BUS_DEFAULT_ADDRESS is already used would it then not make
> more sense to use DBUS_SESSION_BUS_DEFAULT_ADDRESS for autoconf too instead
> introducing a different switch ?

Also using the term "with-dbus-transport" does not distingish between system and session bus. 

To get this patch into dbus repo please rename the option to --with-dbus-session-bus-default-address.
Comment 10 Siraj Razick 2011-12-21 10:29:46 UTC
Created attachment 54649 [details] [review]
Patch to set the default session bus address on windows using ---with-dbus-session-bus-default-address open

new patch with the review comment
Comment 11 Ralf Habacker 2011-12-21 11:42:27 UTC
applied to git master and dbus-1.4
Comment 12 Simon McVittie 2012-01-04 10:10:22 UTC
I've reverted this, along with all changes since a36d4918a6f (the branch point for some local branches I had), because that seems to be the last-known-good point before a merge of (some of? all of?) master (i.e. 1.5) into the dbus-1.4 branch.

This is the second time I've had to revert a merge of 1.5 into 1.4. PLEASE BE REALLY CAREFUL WITH THE STABLE BRANCH. IT IS MEANT TO BE STABLE.

Siraj, I'll cherry-pick your patch back in after giving it some review myself.
Comment 13 Simon McVittie 2012-01-04 10:40:47 UTC
I think this needs more work before it's brought back in.

> +AC_ARG_WITH(dbus_session_bus_default_address, AS_HELP_STRING([--with-dbus-session-bus-default-address=[nonce-tcp:/autolaunch:/tcp:host:port]],[Transport Type to be used (default: nonce-tcp:)]),with_dbus_session_bus_default_address=$withval,with_dbus_session_bus_default_address=nonce-tcp:)

This suffers badly from Bug #38201 - it's not at all clear what "default address" means (see that bug).

I believe the thing Siraj is setting is actually the default address for dbus-daemon to *listen on* - so it can be something like "nonce-tcp:" which describes a class of possible addresses. dbus-daemon can happily listen on "nonce-tcp:", which means "bind to an unspecified port, and see what the kernel gave you" - similarly, on Unix it can listen on "unix:tmpdir=/tmp", which means "generate an unspecified name in /tmp".

It is not the default address for libdbus clients to *connect to*, which would have to be more specific. You just can't connect to "nonce-tcp:" or "unix:tmpdir=/tmp" - it's meaningless, there isn't enough information.

However, you *can* connect to the address that a dbus-daemon listening on "nonce-tcp:" or "unix:tmpdir=/tmp" ends up with, which is something like "nonce-tcp:noncefile=C:\Temp\RRRRRRR;host=127.0.0.1;port=PPPPP" or "unix:abstract=/tmp/RRRRRRRR" where RRRRRRRR is a random string and PPPPP is a random port. You have to discover that address from the dbus-daemon somehow, either via DBUS_SESSION_BUS_ADDRESS or autolaunch.

If autolaunch on Windows works like it does on Unix, then the right thing for libdbus clients in the absence of a DBUS_SESSION_BUS_ADDRESS environment variable is always to fall back to "autolaunch:" - just like they do on Unix - which can just be hard-coded.

The fact that the Unix/Windows duality and the Autotools/CMake duality get conflated just clouds this further. We need to make this clearer (Bug #38201) if we're going to make any progress.
Comment 14 Simon McVittie 2012-01-04 11:55:31 UTC
I think Siraj's patch, plus my patches on Bug #38201, should address this.

Let's solve this in master first, test it, get it working, then only backport to 1.4 when we know what the right answer is.

Siraj's patch remains in master for the moment, but not in 1.4.
Comment 15 Simon McVittie 2013-05-10 17:12:51 UTC
Fixed since 1.7.0.


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.