Bart Van Assche <bvanass...@acm.org> writes:
>> 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:
>
> Are there any features for which (C) is the only option because both
> (B) and (A) are impossible?
Yes, there have been in the past. I don't remember details of any
particular one, unfortunately, but it was actually this condition that
caused the creation of the machine/system directories. They were
created out of need not out of desire. In particular, I do remember
spending hours trying to come up with a configure test that could
accurately measure something on hpux vs something else. The end result
was it was only possible at run time, but that was a bad place to do it
for different reasons.
Remember that one of the other goals of configure was to never do a
configure-time-compile-and-run-to-test type situation, because this
breaks cross compilation. Though we try to do that sometimes (byte
ordering tests), there is always a flag to set when you can't do that.
I wish I had a solid example of when a system/machine file was required
but I don't have that good of a memory.
I will say that I always opted for including "freebsd.h" when
"freebsd9.h" wasn't available, and failing that including "generic.h".
But even that turned out to be problematic because at some point
something was available from 6-9 but not 1-5 and you're stuck having to
create a file for nearly every major os version. Icky.
In the end, it looks a bit cleaner to have defines that have to be set
manually (which are sometimes feature inclusions like mib modules to
include on solaris) in a file specifically for that architecture rather
than lots of config_require(module, solaris) type things in the headers
themselves.
There is no perfect, certainly.
> 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.
If you've found that, that's a broken test. My memory says that all
tests required by config_require() MUST be ahead of the mib-module
processing system. Anything that occurs after it shouldn't be there and
it should be up higher.
> 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?
We (my last employee) received a patch from a company that implemented a
cmake build system for some percentage of the code. It was better in
many ways and had issues in others as it was a different form of
complexity. But it was also incomplete, but a start. The goal was to
put that into a public git branch but looking quickly I don't see that
done. I'll try to push some buttons and see if I can get that done.
> 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.
I think you'd be surprised at how many people assume "it wasn't marked
internal, therefore I assumed it was public". Dave Shield was much much
better at marking items public vs private and argued heavily for that
worthy cause. The problem is that if you don't know whether someone is
using it, then you have to assume that all symbols safe to remove or
not. In general in the past history we've always shied away from
removing stuff unless we know there is a source of conflict. And there
have been sources of conflict, though not many.
--
Wes Hardaker
Please mail all replies to net-snmp-coders@lists.sourceforge.net
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
