> TA> It's a start, but I think our current approach of shipping all
> TA> autoconf variables in net-snmp-config.h is even more flawed than
> TA> that. See some random Debian bug (wrt. some other software) on the
> TA> topic:
>
> TA> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363173
Wes> We shouldn't stop shipping (installing) the results of our configure
Wes> tests. It tells people all about how the package was compiled. It
Wes> drastically simplifies the majority of the coding issues people have
Wes> in the real world.
Wes> But not installing the config.h file is right out because it's simply
Wes> not harmful to do so.
Agreed - there's too much useful stuff in net-snmp-config.h not to
include it in the distribution.
But I don't think that's what Thomas was suggesting.
Wes> The people that are complaining about conflicts
Wes> are likely just as lazy and don't want to do their own header analysis.
That's not really fair, Wes.
There are several defines in our config.h file with fairly generic
names, that are quite likely to clash with similar autoconf settings
from another package. For example:
#define LOGFILE "/usr/adm/snmpd.log"
Is it really that unimaginable that a different package might also
define LOGFILE?
Why should someone have to go to all of the work of analysing our
config file, and picking out all of the relevant definitions - just
because we were too lazy to change this to something more unique, like
NETSNMP_LOGFILE?
Let's take a step back :-) What is the real problem here?
As I see it, there are three general types of entry in the config.h file:
a) Net-SNMP-specific settings - stuff that's only meaningful to our code.
(e.g. DEFAULT_MIBDIRS, USE_REVERSE_ASNENCODING, etc)
It probably doesn't matter if an application includes these, as
they're unlikely to clash with anything from another autoconf-based
library.
b) Generic system-related settings
(e.g. HAVE_SOME_HEADER_H, HAVE_SOME_FUNCTION)
It probably doesn't matter if an application includes there, as they
ought to be consistent with the equivalent settings from another
autoconf-based library. Maybe the compilation would throw up a few
warnings, but nothing too critical.
c) Generically-named, Net-SNMP-specific definitions
(e.g. VERSION, LOGFILE)
This seems to be where the source of most conflicts would lie - and
I'm not sure there's an easy way to resolve these in general. One
option would be to rename all such definitions to be Net-SNMP-specific
(e.g. NETSNMP_VERSION, NETSNMP_LOGFILE). Another possibility would be
to extract such definitions into a separate header file, that could
easily be omitted.
As a first pass, I'd be tempted to separate out the Net-SNMP settings
(a & c above) from the system-configuration information (b), and list
these in two separate header files. That feels a much cleaner
arrangement than our current rag-bag mix.
It's clearly not a full solution, but it might be a start.
Thoughts?
Dave
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Net-snmp-coders mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
