Re: [SyncEvolution] dbus-server-reorganization progress
On Mo, 2011-07-18 at 15:30 +0200, Chris Kühl wrote:
On Fri, Jul 15, 2011 at 4:37 PM, Patrick Ohly
<patrick.ohly(a)intel.com> wrote:
> On Do, 2011-07-14 at 16:14 +0200, Chris Kühl wrote:
> No, not quite. I wanted to avoid the need for the -gen.am trick in
> src/dbus-server by linking the syncevo-dbus-server in src, as before.
>
Ok, good. Having a Makefile-gen.am in src/dbus-server just for the
backends always felt wrong to me anyway.
> I checked out your branch and, after I couldn't figure out why autotools
> didn't link the registry files into syncevo-dbus-server, implemented my
> proposal. Have a look at dbus-server-reorganization-pohly.
>
> It starts with a commit which combines all the registry files into an
> utility library. Adding them as source to each executable was just plain
> laziness.
>
> Then the revised "move to dbus-server" patch adds a
> libsyncevodbusserver.la utility library in src/dbus-server which is used
> to link syncevo-dbus-server in src.
>
Unfortunately, I'm still getting the same issue. Here is the first error I get.
[...]
I'm assuming this was working for you so I'm not sure
what's going on on my end.
I must admit that I pushed my proposal without enough testing. Oops.
What's probably happening is this:
* the register classes are now all in a .a lib
* nothing depends on these object files when linking the executables
* they don't get into the executables
*This* and not laziness in defining the rules must have been the reason
why previously, these classes were listed as source files of all
executables. The resulting object files are then always linked into the
executable.
I'll check whether there is an easy fix. If not, then we'll have to go
back to compiling the sources files multiple times.
--
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.