On Tue, Jun 14, 2005 at 09:38:43AM +0100, Dave Shield wrote: > On Mon, 2005-06-13 at 21:05, Magnus Fromreide wrote: > > On Mon, Jun 13, 2005 at 03:54:14PM +0100, Dave Shield wrote: > > > I've just committed a patch to the main development tree, > > > that renames the offending routine in the Net-SNMP source, > > > while leaving an (optional) compatability wrapper. > > > Would similar patches to remove other just as ugly warts be considered? > > That was the intention of proposing this mechanism, certainly. > Matthew's problem was simply a particular example of a more > general issue. We've started trying to define cleaner API > names for new code, but there's a lot of potentially ambiguous > earlier stuff. > I'd hoped to trigger a discussion of whether this approach > seemed a sensible way forward. > > > > My first choice to kill would then be the PACKAGE_* macros. > > Ummm... isn't those a standard part of the configure mechanism? > The main "configure" script certainly gives that impression.
They are, but there is nothing that would prevent an #if 0 #endif around them, and they are a problem just because they are predefined since they prevent autoconf checks for other things in net-snmp headers. I have for example used autoconf to verify the existance of a myvoid field that showed up somewhere around 5.2, the test right now is AC_CHECK_MEMBERS([struct netsnmp_whatever.myvoid],,,[ #undef PACKAGE_* #include <net-snmp/net-snmp-config.h> #include <net-snmp/whatever.h>]) which is rather annoying and since those macros are unused in the net-snmp source I think they shuld go away. > If not, then something like NETSNMP_PACKAGE_* might be an idea. I do not think it is needed, otherwise it would be the right thing to do for some of those macros. To be honest quite a few macros in net-snmp-config is used only in a single place and aren't autoconfed either, and others are of interest only for the agent so they should preferably move out of net-snmp-config.h. I will return to this later. > > What is the transition plan for deprecation of the old calls? > > This is actually a general question - how old code should be supported? > > Well, the first thing is probably to agree on whether this is an > appropriate mechanism or not! :-) > We've always had a policy of supporting backward compatability > as much as possible, to try and avoid breaking existing code. > There was something of a hiccup from v4->v5, but even there we > tried to keep things working. > > If we can gradually start to separate "current" APIs from those > we consider obsolete, then we've got a chance to work towards a > clean, core API for those that need such a thing, while retaining > the existing melange for those that just want code to keep working. I very much hope for this - the question is what to consider obsolete. /MF ------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61" plasma display: http://www.necitguy.com/?r=20 _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
