On Wed, 2011-06-29 at 10:49 -0700, Patrick Ohly wrote:
On Wed, 2011-06-29 at 09:22 -0700, Patrick Ohly wrote:
> On Wed, 2011-06-29 at 18:06 +0200, Chris Kühl wrote:
> > The "defaultPeer" value lives in default/peers/foo/config.ini, while
> > I'd expect it to be in the .config/syncevolution directory because
> > it's global.
>
> Your expectation is correct. Jussi reported something similar recently:
>
https://bugs.meego.com/show_bug.cgi?id=19464
>
> > This is triggered in the test TestMultipleConfigs.testSharing. Anyone
> > see anything obvious?
>
> I'll have a look.
I still can't reproduce it:
$ PATH=.:$PATH ~/src/syncevolution/test/test-dbus.py -v
TestMultipleConfigs.testSharing
set up configs and tests reading them ... ok
----------------------------------------------------------------------
Ran 1 test in 2.239s
OK
$ cat test-dbus/config/syncevolution/config.ini
# the peer which is used by default in some frontends, like the sync-UI
defaultPeer = foobar_peer
This is with SyncEvlution master commit 487c105a15, compiled with
--disable-shared --enable-static outside of the source directory.
I'll also try with --enable-shared, just in case.
Also works. I'm compiling on Debian Stable, with clang 2.9. I also tried
with g++ 4.5.2, same result.
I'm at a complete loss right now. The writing of defaultPeer happens
inside SyncConfig.cpp's copyProperties(), the first one with more
parameters.
toProps.setProperty(name, value, prop->getComment(),
isDefault ? &value : NULL);
Is called. toProps is a MultiplexConfigNode which looks up the property,
determines that it is global (GLOBAL_SHARING), and then invokes
setProperty() on the corresponding underlying node, which in my case
(syncevolution --daemon=no --configure defaultPeer=foo @default) ends up
in ~/.config/syncevolution/config.ini. Here's the call stack:
#0 SyncEvo::FileConfigNode::setProperty (this=0xd9dea0, property=..., newvalue=...,
comment=..., defValue=0x0)
at /home/pohly/syncevolution/syncevolution/src/syncevo/FileConfigNode.cpp:268
#1 0x0000000000862312 in SyncEvo::FilterConfigNode::setProperty (this=0xda2680,
property=..., value=..., comment=..., defValue=0x0)
at /home/pohly/syncevolution/syncevolution/src/syncevo/FilterConfigNode.cpp:80
#2 0x00000000008619c3 in SyncEvo::MultiplexConfigNode::setProperty (this=0xda4400,
property=..., value=..., comment=..., defValue=0x0)
at /home/pohly/syncevolution/syncevolution/src/syncevo/MultiplexConfigNode.cpp:106
#3 0x000000000083b261 in SyncEvo::copyProperties (fromProps=..., toProps=...,
hidden=false, unshared=false, allProps=...)
at /home/pohly/syncevolution/syncevolution/src/syncevo/SyncConfig.cpp:2023
#4 0x000000000083b4a5 in SyncEvo::SyncConfig::copy (this=0xda2710, other=...,
sourceSet=0x7fffffffb390)
at /home/pohly/syncevolution/syncevolution/src/syncevo/SyncConfig.cpp:2046
#5 0x000000000075ad0f in SyncEvo::Cmdline::copyConfig (this=0x7fffffffd6e0,
from=..., to=..., selectedSources=...)
--
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.