> Looking inside my copy of automake (argh perl..)
Oh man. How I wish autoconf used perl. I'd rather read perl than m4. In
fact I'd rather read perl and eat a box of thumbtacks than read m4.
> I'm a bit frustrated that, out of the can, the source distribution tries
> to run autoheader from a ./configure; make. I can't believe this is
> desirable. Is there a fix which is trivial for you here?
>
> I feel that a delievered tarball should not require, nor try, to use any
> of the suite of autotools unless the consumer does something especially to
> request their activation.
I agree with you, and I believe the authors of those tools agree with you as
well, as it works correctly (i.e. the way you describe) on my system.
I think there are two unrelated problems here. One is aclocal failing, but
I'll come back to that below. The other problem is that, since you're using
the source tarball generated by automake, you've already got Makefile.in's,
and the instructions in README.maint don't apply to you; instead try the
"configure/make/make install" instructions in the INSTALL file. That
shouldn't run aclocal, autoheader, automake, or autoconf; it should just
run the configure script and then build stuff. (Let me know if that's not
the case.)
(As you point out, part of the problem with following the README.maint
instructions is that autoheader fails because acconfig.h isn't included in
the source tarball. I don't know why automake doesn't include it by default;
I've just added it to the list of files to include so it will be in future
tarballs, and have attached a copy to this message. If you still want to go
the aclocal/autoheader/automake/etc. route, put this file at the top of the
sysadm_base tree.) Incidentally, the reason it doesn't fail for other people
following the instructions in the README.maint file is that they're building
in a source tree which was checked out from a repository which includes
acconfig.h. Which reminds me, I still haven't set up a rhino CVS tree on
oss.sgi.com yet...)
As far as aclocal choking on AM_PROG_LIBTOOL, that shouldn't happen. I
assume you're running SuSE? :) I built this on SuSE 6.4 boxes not too long
ago; what versions of autoconf, automake, and libtool do you have?
--Rusty
#ifndef _SYSADM_CONFIG_H
#define _SYSADM_CONFIG_H
@TOP@
/*
** acconfig.h
**
** This file contains macro definitions & comments which are used by
** "autoheader" and "configure" to generate config.h.
*/
/* Define if the C++ compiler supports a built-in bool type. */
#undef HAVE_BOOL
/* Define if the C++ compiler supports namespaces. */
#undef HAVE_NAMESPACE
/* Define if we can use _getpwent_no_yp to control whether getpwent(3C)
** uses yp.
*/
#undef HAVE__GETPWENT_NO_YP
/* Define if we can use _getpwent_no_shadow to control whether getpwent(3C)
** uses shadow passwords. If this isn't set, it's assumed that getpwent
** etc. won't handle shadow passwords for us, and we have to call getspent
** ourselves.
*/
#undef HAVE__GETPWENT_NO_SHADOW
/* Define if we have sginap(2), etc.
*/
#undef HAVE_SGINAP
/* Define if we have deflt.h */
#undef HAVE_DEFLT_H
/* Define if we have fam.h */
#undef HAVE_FAM_H
/* Define if we have xpasswd in pwd.h */
#undef HAVE_XPASSWD
/* why do I have to have these? PACKAGE and VERSION are defined by
AM_INIT_AUTOMAKE, and the examples don't say anything about having
to mess with these things elsewhere. */
#undef PACKAGE
#undef VERSION
/* These are required? by GNU gettext. */
#undef ENABLE_NLS
#undef HAVE_CATGETS
#undef HAVE_GETTEXT
#undef HAVE_LC_MESSAGES
#undef HAVE_STPCPY
@BOTTOM@
#endif /* _SYSADM_CONFIG_H */
|