Re: On the nature of backward comparability

Thanks Wes for the elaborate write-up.

On 05/14/18 14:07, Wes Hardaker via Net-snmp-coders wrote:
> The struggle with all of this, of course, is that the code begins to
> look a little crusty in spots while we try to maintain support for so
> many operating systems that we don't even have the ability to test
> against internally.  Developing the code ended up in roughly the
> following notions/priorities:
> 
> A) write a configure test for any struct/api/feature/etc that wasn't
>     portable across all platforms.
> 
> B) failing the ability to do that, see if you could determine it at
>     runtime (see agent/auto_nlist as a reference point).
> 
> C) Failing that, create and use ifdefs and put defaults and exceptions
>     into two specific places:
> 
>     C1) hardware defines would go into include/net-snmp/machine headers
>     C2) OS based defines would go into include/net-snmp/system
> 
>     This last step greatly cut down on the number of machine specific
>     ifdefs.  Much more of the code used to look like:
> 
>         #if defined(solaris) || defined(hpux9) || defined(freedbsd8) ...
> 
>     and we greatly reduced those.

Are there any features for which (C) is the only option because both (B) 
and (A) are impossible? I have not yet encountered any such features. 
Personally I think we should get rid of the include/net-snmp/machine and 
include/net-snmp/system headers and also of any code in the form of 
#ifdef ${uname}${version}.

> D) Ideally, compartmentalize code into files that could be included and
>     excluded at will via configure flags.  The mib-modules are done this
>     way, as are the transports, SNMPv3 security modules, etc.  You get to
>     compile in only te items you need.  And the mib-module's hardware
>     abstraction layers (HAL) meant that the code that dealt with SNMP
>     representations could be put into one file, and all the system
>     dependent code could be put into OS or hardware specific files to
>     implement the abstraction layers.  This is what lead to directories
>     of code files like agent/mibgroup/host/data_access, for example.

Some of the config_require() statements are guarded by symbols defined 
in <net-snmp/net-snmp-config.h>. Is it guaranteed that 
<net-snmp/net-snmp-config.h> is available and complete at the time the 
config_require() analysis happens? Every time I rebuild the Net-SNMP 
code base I notice that some of the configure checks happen after the 
config_require() analysis has finished.

> So, do we have to stay like this in the future?  Not necessarily.  We
> could abandon all past release stability and proclaim that we're making
> a separation point and that Net-SNMP 6.0 will be a break-API point.  In
> fact, we've talked about that multiple times in the past.  And we've
> even talked about it recently, and in fact since we have a large patch
> implementing CMake support over autoconf still to apply and I always
> figured that would be a good point to move to a new 6.0 release with a
> completely redesigned build system.  Even with this new build system,
> some of us had a discussion for how long to support *both* configure and
> cmake, even though we knew how painful that would be.  And there is a
> strong question of how well cmake will support all the embedded build
> environments we know Net-SNMP is being used in.

Does this mean that some developers are working since considerable time 
on a conversion of the build system to cmake but that that patch is not 
yet publicly available? Will other developers have the chance to review 
that patch before it gets applied?

> And more importantly, we don't know what APIs and what #defines are
> being used in code bases out in the wild.  The original code, way way
> way back when, was not properly architected to provide a public/internal
> names space and we suffer from that still today. 
> 
> So before we go forward and remove #defines because we think they aren't
> needed, and before we remove include files in the
> include/net-snmp/system directory because they're old operating systems,
> I ask you to think about whether or not we're willing to let that
> segment of a potential user base go so they'll no longer receive bug
> fixes, etc.

Personally I consider it very important to maintain backwards 
compatibility for the *documented* Net-SNMP API. However, I'm not sure 
we should support users who rely on symbols from 
<net-snmp/{machine,system}/...> that are neither documented nor have a 
NETSNMP_ prefix.

Thanks,

Bart.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot