On Do, 2011-07-14 at 16:14 +0200, Chris Kühl wrote: > >> I said "almost" on par because I've been having issues when building > >> with --disable-shared and --enable-static. When trying this I get an > >> error telling me to add -ldl to the LDFLAGS which I've done and it > >> does in fact seem to build correctly. However, with this, the backends > >> don't get registered and I, of course, get tons of problems when > >> running the tests. This issue exists in the first commit on my branch > >> which moved the dbus-server over to its own directory. However, > >> everything does seem to build and work fine with only --enable-static > >> specified which is what I've been using for running the tests. > > > > Did you notice the rules which add the backend's *Register.cpp files to > > the syncevo-dbus-server? > > > > src/Makefile.am (generated from Makefile-gen.am) contains: > > BACKEND_REGISTRIES = ... backends/.../*Register.cpp > > > > This is then added to syncevo-dbus-server via: > > CORE_SOURCES += $(BACKEND_REGISTRIES) > > syncevo_dbus_server_SOURCES = \ > > ... > > $(CORE_SOURCES) > > > > Yes, I've got that in my src/dbus-server/Makefile-gen.am. In fact, > that's why I had to use the "-gen." That appears to give me what I > need in the generated Makefile.am but maybe I'm fumbling something. > > > The easiest solution might be to keep linking the main > > syncevo-dbus-server in "src", but with all code compiled in a > > sub-directory into a helper library. > > > > I attempted this but had the same results. Here is the patch I tried: > http://pastebin.com/L8BKtY7Z > > Does that look like what you had in mind?
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. 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. I was undecided whether I should use hyphens in the library name. The other libraries don't use the, so I decided against it. Admittedly makes it harder to read. Speaking of naming, should src/dbus-server rather be src/dbus/server? It would be more consistent with "anything related to SyncEvolution D-Bus in dbus". Also plays nicer with tab completion of file names in the shell. I often ended up with dbus<tab><return> taking me to the "dbus" directory instead of completing to "dbus-server". -- 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. _______________________________________________ SyncEvolution mailing list [email protected] http://lists.syncevolution.org/listinfo/syncevolution
