[Bug 27178] don't install private headers, and privatize most of the API/ABI

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=27178





--- Comment #9 from Cosimo Alfarano <cosimo.alfarano at collabora.co.uk>  2010-03-24 12:56:49 PST ---
> It seems that the daemon uses these, so they need to be visible to it as well
as within the library, but (e.g.) Empathy and Moblin don't need these headers
or the symbols they export. Am I understanding correctly?

Yes.
Following the chat about symbols we had a week ago, I pointed them out in order
to clarify what might be split into a convenience lib to be used only by the
service, and what in the official shared one.

Substantially this set (the same you quoted)

observer.c
dbus-service.c
channel.c
channel-factory.c
channel-text.c
log-store-factory.c
debug.c
action-chain.c

contains symbols that are never accessed outside the set itself and main(),
which can statically link the convenience library, including them all, and
dynamically link the official library.

This is true if we exclude tests/ which I don't think is a problem.

Clients will link only the official library.
This to avoid most of the non public symbols to be appear in the official
library.


--- Comment #10 from Simon McVittie <simon.mcvittie at collabora.co.uk>  2010-03-25 06:51:55 PST ---
(In reply to comment #9)
> Substantially this set (the same you quoted)
> 
> observer.c
> dbus-service.c
> channel.c
> channel-factory.c
> channel-text.c
> log-store-factory.c
> debug.c
> action-chain.c
> 
> contains symbols that are never accessed outside the set itself and main(),
> which can statically link the convenience library, including them all, and
> dynamically link the official library.

It's not quite that simple, because having two copies of the same code in the
same process isn't going to work well; there's one in the convenience library,
and another in the shared library. There are a couple of ways this can go:

1) Link the daemon against the convenience library, not the static library
(dbus-daemon and friends link libdbus in this way). This would break
third-party plugins into the daemon (if we want that possibility?), if those
plugins linked the shared library.

2) Make libtelepathy-logger a minimal library for clients. Move the bits that
only the daemon needs into src/, and have clients, the daemon, and any future
plugins all link against the shared library. This would mean that any symbols
needed by both src/ and the internals of the library would have to be exported.
(Mission Control works somewhat like this: libmcclient is a small client
library, which also contains code used by both clients and the daemon.)

This can of worms gets nastier if we have GPL vs. LGPL considerations, and want
to make the library LGPL-only for maximum applicability. Is it possible to
restrict the GPL (Empathy-derived) code to src/ and have libtelepathy-logger be
LGPL, or is there some LGPL code that's definitely needed by clients of the
logger?

> This is true if we exclude tests/ which I don't think is a problem.

Tests can always be linked against the convenience library directly if
necessary - a couple of tests in telepathy-glib do that, to gain access to
hidden internal symbols.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.