[Nagiosplug-devel] The various plugins/*.h.in files

[Jeremy T. Bouse]

On Thu, Mar 13, 2003 at 12:52:15AM -0500, Karl DeBisschop wrote:
> On Wed, 2003-03-12 at 20:56, Jeremy T. Bouse wrote:
> > 	Just replying back to my own post to say that the testing I did with the
> > removal of these *.h.in files and renaming them as just the *.h files and
> > modifing the plugins/Makefile.am and configure.in works fine... 
> > 
> > 	Just wanting to get another opinion on if this is something we want to
> > move to clean-up the build or not before I commit it... I have it in a seperate
> > checkout directory so I can continue work with other tasks without committing
> > that change... 
> > 
> > 	What it would entail is adding plugins/common.h, plugins/netutils.h,
> > plugins/popen.h, plugins/utils.h and plugins/version.h (whether
> > this is even needed at all is questionable); removing plugins/common.h.in,
> > plugins/netutils.h.in, plugins/popen.h.in, plugins/utils.h.in and
> > plugins/version.h.in; and modifing configure.in and plugins/Makefile.am...
> 
> version.h is now completely cruft and should be removed. I'll let you do
> it since you have already adjusted Makfile.am/configure.in
> 
> I agree that the others also no longer seem to need to be carried
> through autoconf. I aggree that the change should be made.
>
	Okay then I'll go ahead and get the changes committed then... I just
made a seperate checkout directory for that testing so I'll get it updated and
commit it this evening...
 
> > 	As well I'd like to go ahead and remove install-sh, missing and
> > mkinstalldirs as they would be install'd by the 'automake --add-missing --copy'
> > line in tools/setup or the autogen.sh I added...
> 
> I have a problem with autogen.sh.
> 
> It's often not realized that you can (should?) build in subdirectories
> of nagiosplug. So
> 
> mkdir build-rh72 build-rh73 build-sol7 build-debian build-dist
> 
> then when your working with you single NFS mounted home directory on the
> various test platforms ypu work with, just cd into the appropriate
> directory and build. No copies from one tree to the other, no repeated
> CVS updates.
> 
> This works so long as you don't 'configure' in the top-level directory.
> 
	Actually I've been doing the build sub-directories to do builds although
I ran into a problem on Solaris 8 compile farm at SF but didn't have the problem
with Solaris 9 in the office or on my Linux machine... I just do the following:

mkdir <build dir>
cd <build dir>
../configure
make

	It builds fine... No real need to re-run autoconf, and family everytime
as the Makefile.in's and configure script generated should be universal... The
autogen.sh I have included right now prolly does have some problems it was
something really quick I threw together here locally... If no one uses it or
what not we can remove it and I'll just use it locally...

> Autogen.sh breaks this. The automake/autoconf stuff a developer does
> really should be kept separate from the configure that a user does.
> 
> Perhaps one way to do this is to invoke tools/setup from autogen.sh - so
> as a delevloper, I can run tools/setup, and as a user I can run
> autogen.sh
> 
> But the current approach is flawed because it requires maintaining the
> same scripted actions in both tools/setup and autogen.sh
> 
> Does autogen.sh paly some sort of sacred role withinh the debian build
> process? We do redhat build pretty nicely -- 'rpm -ta tarball' and
> you're done. If possible, I'd like to support .deb creation as easily,
> and your debian backgorund could help.
> 
	Actually autogen.sh has nothing really to do with Debian package
builds... I know being a Debian package maintainer myself... Debian adds it's
own subdirectory debian/ and anything it needs for making the package is
contained within it... I know Turbo who maintained the netsaint plugins for
Debian officially has the nagios package build and in the Debian unstable distro
at this time but no nagios plugin package... He had told me that he was waiting
for a stable release but I haven't checked with him since 1.3.0 went final... If
he doesn't have time for it I may go ahead and get in contact with him and see
about handling the packaging of the plugins for nagios myself since I'm on the
devel team and working closely enough with it already...

	Jeremy