* Rusty Ballinger (rusty@xxxxxxxxxxxxxxxxxx) [001012 05:08]:
> > 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
Well, yes and no; if I want --without-fam they do.
Mainly I was just playing around trying to figure out why it wasn't
building.
> 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.)
I thought it wasn't. Now I am thinking 'pilot error'.
It was my impression that autoheader was run with ./configure; make when i
had an inconsistent sent of autoconf/make/libtool installed.
Is it appropriate to ship a package using auto* without including the
./libtool file?
> (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?
Oh geez. I've been using too many machines.
On the 6.4 box libtool wasn't installed.
That issue goes away.
Anyway, here's a pointer to the rename issue:
/usr/share/aclocal/libtool.m4:
[...]
dnl old names
AC_DEFUN(AM_PROG_LIBTOOL, [indir([AC_PROG_LIBTOOL])])dnl
That's from the libtool 1.3.4 (1.385.2.196 1999/12/07 21:47:57)
> --Rusty
-josh
--
_,,wwww,,_
,wØØØ^"^ØØØØØØw,
.dØØØØI,_,Ø***ØØØØb. _____ _____ ______ ____
.ØØØ^ØØ*^'¸ ,¯'ØØØØØ. / ___/__ __/ ___// ____/ / _/___ _____
:ØØØbwww** `7,'ØØØØ: \__ \/ / / /\__ \/ __/ / // __ \/ ___/
`ØØØØØØØ7' dØØØØØØ' ___/ / /_/ /___/ / /___ _/ // / / / /___
`7ØØØØØ' ,* ØØØØØ7' /____/\__,_//____/_____/ /___/_/ /_/\___(_)
`*Øbb. "Ø, ØØØ*'
¯'^^ ^' '¯
--
Source code, list archive, and docs: http://oss.sgi.com/projects/rhino/
To unsubscribe: echo unsubscribe rhino | mail majordomo@xxxxxxxxxxx
|