[rrd-developers] librrd4 dependancies

[Sebastian Harl]

Hi Tobi,

On Mon, Jun 29, 2009 at 01:58:08PM +0200, Tobias Oetiker wrote:
> Today Sebastian Harl wrote:
> > Imho, the best thing to do would be to separate graphing into it's own
> > library, say librrd-graph. Just doing so should require adapting the
> > build system only. However, this introduced backward-incompatible
> > changes to the API and ABI of librrd, so it would require a major soname
> > version bump, so Tobi has to decide about that. I do not expect that
> > lots of C programs use rrd_graph*(), so only few other projects should
> > be affected by that change and require code (and build system) changes
> > [1].
> 
> how about having the following structure
> 
> librrd - including the graph stuff and puling in the rest from
> librrd-base
> 
> this means that people who want only the base stuff can link
> against librrd-base ... and it would not break existing usage as
> linking against librrd would pul in librrd-base automatically.

I was thinking about that as well but I see a couple of problems and
(rather minor) disadvantages when using that approach:

 * People using the static library would still need to change their
   build system because static libs do not have a NEEDED entry [1], i.e.
   they cannot specify any dependencies. I'm unsure if that change thus
   should still be considered to be an ABI breakage.

 * I'm also unsure if that's going to work on all platforms even in the
   case of shared objects. If I recall correctly (and I'm quite
   uncertain if I do), some operating systems / dynamic loaders do not
   support recursive loading of shared objects [2] and instead require
   the application to link against all dependencies of some library as
   well. Anybody on this list who has a more in-depth insight into this?

 * By using my approach, applications not using rrd_graph*() (which, I
   suppose, is the more common case) would automatically drop their
   dependency on cairo and pango without requiring any manual changes
   (in Debian those packages would simply be rebuilt).

 * Imho, graphing has nothing to do with round robin databases by
   itself. Even though it's probably one of the main reasons for people
   using RRDtool, I'd call it an "add-on". So separating that into some
   librrd-graph would imho be the "semantical" better choice. This is
   mostly a matter of personal preference though.

Comments?

Cheers,
Sebastian

[1] In case of ELF binaries. I don't know how that field is called in
    other binary formats or whether it exists at all in all binary
    formats.

[2] Which, e.g., would be the case if there's nothing like NEEDED.

-- 
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/

Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.oetiker.ch/pipermail/rrd-developers/attachments/20090630/e5404bc3/attachment.bin