On Do, 2010-11-04 at 01:17 +0000, knipp(a)m-otion.com wrote:
On Tue, 2 Nov 2010, Patrick Ohly wrote:
> Attached is a patch, entirely untested. Should apply to the
> SyncEvolution 1.1 source archive [1].
The bad news first:
The patch doesn't work.
No surprise, I never really expected it to be complete ;-}
If you look deeper into findLocalDataStoreByURI, which calls
findLocalDataStore (both in syncsession.cpp), you'll find a call into
sysync::TSyncDataStore::isDatastore (syncdatastore.cpp:146).
There is a comparison between the target and the name of the data store.
The target is "Contacts", but fName.c_str() gives "addressbook".
"addressbook" is the real local name. The "URI" property sets an
alias.
That should be checked somewhere by the code, so if you update your
SyncEvolution contact to have "uri = Contacts" in
"addressbook/config.ini", then it might work without the explicit
isDatastore hack.
I currently don't know, where the fName comes from, it is not the
uri
parameter from the configuration.
Run with a higher loglevel (10) and you'll see the XML config dumped,
which has <datastore name='addressbook'> ... <alias
name='Contacts'></datastore> if an URI is configured.
I've attached a patch for showing you the changes, but it's
not meant to
be used as part of a release.
Do you think you can try with URI set and without dirty hacks? I don't
have a Sony Ericsson phone to test with myself.
During the gdb session I've read several times “value optimized
out”,
therefore I tried to switch off the optimization of -O2 by resetting the
compilation flags by
SYNTHESIS_CFLAGS=-g CFLAGS=-g ./configure --prefix='/home/knipp/opt'
but instead it needed
CXXFLAGS=-g ./configure --prefix='/home/knipp/opt'
Is SYNTHESIS_CFLAGS used somewhere?
Yes, internally. As you found, the right (and normal) way of setting
your own compile flags is via CFLAGS (for C code) and CXXFLAGS (for C
++).
Which tools/IDE do you use for SyncEvolution development?
emacs + gcc + gdb. No fancy IDE for me, no thanks ;-)
--
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.