Michael Goffioul writes:
Michael> From my point of view (short intro: Michael Goffioul, Michael> KDEPrint and sKli developer), having access to separate Michael> libraries to perform all the SNMP dirty work is a Michael> plus. Having access to the internal data is much faster and Michael> more reliable than parsing the scli standard output (whose Michael> format can change from one version to the other). So I'm Michael> pretty much in favor of such a development direction. For Michael> the dependency problem, you can still package the whole Michael> source code into one package, containing the various Michael> libraries and the scli executable, and leave the splitting Michael> into separate binary packages to the distro packagers. As Michael> final note, I'll add that having access to the stubs is (at Michael> least for me) as important as for the gsnmp alone. So yes, Michael> putting stubs accessible in separate package/libs is pretty Michael> useful.
I just tried to create a stub library which contains stubs for all IETF MIB modules. The downside of this approach is that the resulting stub library is rather big (4M). The upside is that there is one library with everything included - so all the stubs are readily available. There might be other ways to split things in more reasonable sized pieces. (Or if there someone who can tell me how I can generate more space efficient stubs, I would love to do so.)
Generate and compiling gsnmp/scli stubs for all IETF modules also showed some bugs in the stub code generator. (Yeah, some IETF MIB modules use descriptors that are reserved words in C. ;-) But in general, I tend to like the setup with three source packages - one for the gsnmp library, one for the stubs and one for scli. But getting all the packaging stuff right might take some more time...
/js