[Nagiosplug-devel] New plugins, autoconf & pre-built binaries

[Karl DeBisschop]

On Sat, 2003-03-29 at 18:26, Ton Voon wrote:
> On Saturday, March 29, 2003, at 03:36  am, Jeremy T. Bouse wrote:
> >> 2) I'm having terrible problems with the poll calls in check_cpu as
> >> Darwin does not include sys/poll.h and I can't seem to get them into
> >> lib/ using autoconf 2.13. Works fine in autoconf 2.5x as I use the
> >> AC_LIBOBJ function, but this kicks up lots of fusses when run in 
> >> v2.13.
> >> Another reason to update?
> >>
> > 	Yeah because of the problems with this was partially why the
> > getaddrinfo.[ch] and gethostbyname.[ch] went into plugins/ rather than 
> > lib/, the
> > other part was the linking issues... Didn't make sure to link all 
> > plugins
> > against the socket libraries if they didn't make socket calls which 
> > was what it
> > would have done... Possibly need to consider a libnagiosplugin*.a file 
> > that is
> > socket calls and one for non-socket functions? Also the 
> > AC_CHECK_MEMBERS
> > function that was added for the check_disk plugin (I believe) also 
> > makes a
> > requirement for 2.57 as AC_CHECK_MEMBERS is not in 2.13... So it 
> > almost seems
> > like moving to 2.57 is the way to go... I've also been looking around 
> > and it
> > seems we have a whole lot of tests being done for stuff that doesn't 
> > appear to
> > be used anywhere... This may be from old code who knows, but maybe 
> > before the
> > next release we should take a good look and audit things...
> Sorry, I think I introduced the AC_CHECK_MEMBERS problem because I 
> updated ls-mntd-fs.m4 to fix a Darwin issue. Compiles okay on autoconf 
> 2.52 on my main system.
> 
> Moving to autoconf 2.5x would get my vote as we seem to be left behind 
> as we code around problems which newer autoconfs will fix. I think 
> Karl's objection is that it places a requirement on people that pull 
> the main CVS version, but, with the daily builds and (future) platform 
> packages, maybe that won't be such a problem anymore?

My objection was this: For better or worse, Redhat carries a large user
base, so it can be used as a rough proxy for what level of support we
should depend on. RedHat 8 is not too widely deployed from what I can
tell - most RedHat users are still on 7.3. My concern was if this is a
good proxy (a point that is open to discussion) we would be best served
to delay our dependence on 2.5x until we knew when the successor to RH8
would be deployed.

We now know, and I am comfortable with working with the assumption that
developers will use autoconf 2.52 or better. 

I withdraw my previous concerns.

--
Karl