On Thu, 2010-05-20 at 07:38 -0700, Wes Hardaker wrote: > >>>>> On Thu, 20 May 2010 09:40:06 +0200, Magnus Fromreide > >>>>> <[email protected]> said: > > MF> Now, I would love to hear some kind of comments on this. > > I need to go read the actual patch details, but the ideas look good in > general :-) > > MF> generate-netsnmp_transport.diff: > > IMHO, these should be auto generated in the first place at run-time like > the init_() list is (and how all the mib-module defines are). So this > is the right goal, but probably not the best exact solution. If you do > things like this at autoheader/autoconf time it isn't as clean and > extensible as it would be if you let the end-user drop in new transport > implementations without needing to rerun autoconf (eg, right now if they > create new mib modules they don't need to run autoconf).
Sort of. I did it as a better alternative to using acconfig.in as I detest having to keep the same stuff in two places. With that said I have to admit to like using autoconf for things like this. > MF> I do require that at least one transport is configured but that > MF> is open for debate, there is no real reason to require that save > MF> that the agent becomes utterly useless without any transport but > MF> on the other hand e.g. the Alias transport is enough to get past > MF> that test so maybe I should just skip it. > > I think everything becomes useless if there is no transports, so I think > we should at least warn them they've done something stupid. Always, > IMHO, think of the end-user and do what's right for them (and what's > right for them in this case is an error since it makes no sense > otherwise). > > If they're actually managing to figure out how to config with only the > 'alias' transport then, um, that's not an exception I think we should > test for since they're obviously, um, smart? (Just the 'callback' > transport would likely be not very useful either, but I can actually see > third-party code wanting just that at least). So, let's keep that AC_MSG_ERROR. /MF ------------------------------------------------------------------------------ _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
