rrdtool 1.4.x without graphing support?
|
|
|
||||||||
|
|
||||||||
|
Hi,
On Thu, Nov 05, 2009 at 05:53:20AM +0100, Tobias Oetiker wrote: > Yesterday Ulf Zimmermann wrote: > > Anyone got an idea how much work would be involved to build/patch > > rrdtool 1.4.x to remove graphing support? Library dependency for > > EL4 is just hell at this point. And as I need librrd, I am not > > sure how far I can work with a static build to work with collectd > > together. > > you may want to try the appended patch. > +if BUILD_RRDGRAPH > +RRD_C_FILES += rrd_graph.c \ > + rrd_graph_helper.c \ > + rrd_xport.c \ > + rrd_gfx.c \ > + pngsize.c > +endif […] NB: RRD_C_FILES is later used to specify the source files for librrd. In case this patch is supposed to be included in RRDtool, please note that it provides an easy way to build RRDtool with a different API / ABI. Hence, it requires a different SONAME version (or even better: a different SONAME -- which would be easier to implement as well). Anyway, rather than including this (imho) somewhat hackish way, I'd rather go for splitting the library as discussed before (librrd / librrdgraph). I'm willing to provide a patch for that targeted at RRDtool 1.5 (it will probably require a SONAME version bump, thus, it should imho not be included in 1.4 -- I'd also provide patches for reverse dependencies known to be affected by that). Cheers, Sebastian -- 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 _______________________________________________ rrd-users mailing list [hidden email] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users |
||||||||
|
|
In reply to this post
by oetiker
|
||||||||
|
|
|
||||||||
|
|
In reply to this post
by Sebastian Harl
|
||||||||
|
|
Hi Tobi,
On Thu, Nov 05, 2009 at 11:56:10PM +0100, Tobias Oetiker wrote: > Today Sebastian Harl wrote: > > On Thu, Nov 05, 2009 at 05:53:20AM +0100, Tobias Oetiker wrote: > > > Yesterday Ulf Zimmermann wrote: > > > > Anyone got an idea how much work would be involved to build/patch > > > > rrdtool 1.4.x to remove graphing support? Library dependency for > > > > EL4 is just hell at this point. And as I need librrd, I am not > > > > sure how far I can work with a static build to work with collectd > > > > together. > > > > > > you may want to try the appended patch. > > > > > +if BUILD_RRDGRAPH > > > +RRD_C_FILES += rrd_graph.c \ > > > + rrd_graph_helper.c \ > > > + rrd_xport.c \ > > > + rrd_gfx.c \ > > > + pngsize.c > > > +endif > > [?] > > > > NB: RRD_C_FILES is later used to specify the source files for librrd. > > > > In case this patch is supposed to be included in RRDtool, please note > > that it provides an easy way to build RRDtool with a different API / > > ABI. Hence, it requires a different SONAME version (or even better: a > > different SONAME -- which would be easier to implement as well). > > this patch is not the library split or anything like this ... it > is simply an attempt to help ulf ... issue ;-) > note that there are already similar configure options for libdbi > which enable/disable functionality without changeing the library > version ... Darn, I did not notice that so far :-/ This is not a good thing either (imho). One could argue that taking care of appropriate SONAME version changes is the responsibility of distrib- utors. However, this will create problems for users if done differently on different distributions. > after doing this initial version, and thinking about it I think > adding stub versions of the public graph functions which set > rrd_error when called would be a nicer variant ... leaving the > library interface in place ... This would keep the API unchanged but it *does* change the ABI (the semantic of some functions would change -- dramatically even), thus still requiring a SONAME version change. > > Anyway, rather than including this (imho) somewhat hackish way, I'd > > rather go for splitting the library as discussed before (librrd / > > librrdgraph). I'm willing to provide a patch for that targeted at > > RRDtool 1.5 (it will probably require a SONAME version bump, thus, it > > should imho not be included in 1.4 -- I'd also provide patches for > > reverse dependencies known to be affected by that). > > yes, a split of the library for 1.5 would be cool ... I would > propose the following split: > > librrdclient - access to rrdcached functions - no deps > librrdcore - core rrdtool functions (create/update) - no deps You've been talking about an API-redesign scheduled for 1.5 -- any specific plans for that yet? Also, as of now, this lib would depend on libdbi. If we want to split that out as well, librrdcore would still depend on that unless rrd_fetch() would be split into two functions. Another approach would be to introduce "backend-drivers" (i.e., one handling files, one handling SQL databases thru dbi, etc.). Those drivers could then be loaded dynamically by rrd_fetch(). IIrc, somebody has proposed a "virtual file- system layer" some time ago -- what happened to that? > librrdcached - rrdcached - glib What's that supposed to include and what purpose is it going to serve? Do you want to make rrd_daemon.c:main available thru the/a library? I don't see any benefits from that. > librrdgraph - graphing - cairo pango That's the most important one ;-) > librrd - compat layer - librrdclient librrdcore librrdcached librrdgraph I'm still unsure about details like "does that change the ABI?", etc. (see a previous E-mail in a different discussion on that topic) but, I guess, it might make live a bit easier for users who compile stuff them- selves (rather than having their distributor take care of that), so (*shrug*) why not … ;-) > configure could then automatically disable the bits of rrdtool > which can not be built due to libraries missing NB: "bits" as in "single libraries", rather than features of one library Cheers, Sebastian -- 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 _______________________________________________ rrd-users mailing list [hidden email] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users |
||||||||
|
|
|
||||||||
|
|
In reply to this post
by oetiker
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
|
||||||||
|
|
Attached are the patches and the spec file I used to build a version now on RedHat EL4 without graphing support and no rrdcached.
The spec file is from an older version and I did do some modifications to it, to fit my environment/EL4. As we don't care about ruby, tcl, php or python I used this command to build: rpmbuild -bb --define '_without_python 0' --define '_without_php 0' --define '_without_tcl 0' --define '_without_ruby 0' rrdtool.spec I am now proceeding with a test of building collectd 4.8.1 and to use it to send data to a central server, which will run rrdcached. Ulf. _______________________________________________ rrd-users mailing list [hidden email] https://lists.oetiker.ch/cgi-bin/listinfo/rrd-users  rrdtool.spec (28K) Download Attachment rrdtool-1.4.2-no_graph_patch (6K) Download Attachment rrdtool-1.4.2-no_rrdcached_patch (420 bytes) Download Attachment rrdtool-1.4.2-rrd_restore.c.patch (460 bytes) Download Attachment |
||||||||
| Free Embeddable Forum Powered by Nabble | Help |
