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

[Karl DeBisschop]

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.

> 	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.

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.

--
Karl