Gripe: working on configure now requires Automake installed locally
You seem to be relying on automake's aclocal program to combine the
config/*.m4 files into aclocal.m4. I can see no value in introducing
this additional package dependency, since as far as I can tell aclocal
isn't doing anything for us that 'cat' couldn't do.
I recommend removing config/*.m4 in favor of a single aclocal.m4 file.
This also gets rid of the need for at least one of the broken
dependencies in the toplevel makefile.
For that matter, I don't see any really good reason for having
aclocal.m4 in the first place. If we were maintaining a bunch of
packages that had some reason to share configure macros, aclocal.m4
would make sense. We are not, so there's no really good reason not to
just keep all the configure code in configure.in. Introducing more
files just creates more ways to screw up.
I'd like this to get resolved PDQ. Regression tests are currently
failing for me because the int8-related configure tests are busted.
I can't fix it unless I go and install automake, which I don't
really care to do unless there is a consensus that automake should
become a required tool for Postgres developers.
regards, tom lane
Tom Lane writes:
You seem to be relying on automake's aclocal program to combine the
config/*.m4 files into aclocal.m4. I can see no value in introducing
this additional package dependency, since as far as I can tell aclocal
isn't doing anything for us that 'cat' couldn't do.
We need it if we ever want to use libtool unless you want to include half
of libtool into CVS.
there's no really good reason not to just keep all the configure code
in configure.in.
It's really the same as keeping all of the C source code in one file, you
don't do that either. IMHO, it's a matter of logical organization,
modularity etc. I find setups organized like this much more readable. Many
tests in configure don't interface to config.cache properly;
unfortunately, fixing that makes the tests longer. I don't think a 5000
line file of shell and macro processing is really what you want.
Regression tests are currently failing for me because the int8-related
configure tests are busted.
I already fixed something there.
Well, I'm not proprietory on any of this, I'm just following the book. Let
me know...
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
Tom Lane writes:
You seem to be relying on automake's aclocal program to combine the
config/*.m4 files into aclocal.m4. I can see no value in introducing
this additional package dependency, since as far as I can tell aclocal
isn't doing anything for us that 'cat' couldn't do.
We need it if we ever want to use libtool unless you want to include half
of libtool into CVS.
Huh? libtool doesn't require automake; I've been using it quite
successfully for libjpeg without any automake.
My impression so far of automake is that it imposes a ton of mechanism
and unpleasant restrictions (like, say, not being able to make INSTALL
an absolute path, as any half-sane person would do) in return for darn
little usefulness. I'm going to want to be convinced that it's a good
idea for Postgres...
regards, tom lane
On Mon, 12 Jun 2000, Tom Lane wrote:
Huh? libtool doesn't require automake; I've been using it quite
successfully for libjpeg without any automake.
Okay, then I'll have to investigate more. I'll tell you what, I'll change
`aclocal' to `cat' for the time being. But I'd sure hate to have all the
macro definitions in one file. As someone else once said, you separate
what you test for from how you do the testing -- implementation hiding.
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
On Tue, 13 Jun 2000, Peter Eisentraut wrote:
On Mon, 12 Jun 2000, Tom Lane wrote:
Huh? libtool doesn't require automake; I've been using it quite
successfully for libjpeg without any automake.Okay, then I'll have to investigate more. I'll tell you what, I'll
change `aclocal' to `cat' for the time being. But I'd sure hate to
have all the macro definitions in one file. As someone else once said,
you separate what you test for from how you do the testing --
implementation hiding.
Okay, just to put my two cents in here ... when I played with libtool a
little while back, it was my impression that *without* using automake,
using libtool would be pretty hellish ...
... but, shouldn't automake be a requirement on a developers machine if,
and only if, they modify either the Makefile.am files *or*
configure.in? Like, it should only be a requirement for a select few of
the developers?
The Hermit Hacker writes:
Okay, just to put my two cents in here ... when I played with libtool
a little while back, it was my impression that *without* using
automake, using libtool would be pretty hellish ...
It will be interesting, no doutb.
... but, shouldn't automake be a requirement on a developers machine if,
and only if, they modify either the Makefile.am files *or*
configure.in? Like, it should only be a requirement for a select few of
the developers?
The problem was that I was using the aclocal program, which comes with
automake and Tom didn't want to install that. In all truth, it doesn't do
*much* more than cat, so we use that for now.
--
Peter Eisentraut Sernanders v�g 10:115
peter_e@gmx.net 75262 Uppsala
http://yi.org/peter-e/ Sweden
Peter Eisentraut <peter_e@gmx.net> writes:
... but, shouldn't automake be a requirement on a developers machine if,
and only if, they modify either the Makefile.am files *or*
configure.in? Like, it should only be a requirement for a select few of
the developers?
The problem was that I was using the aclocal program, which comes with
automake and Tom didn't want to install that.
Just to be perfectly clear: I don't have a problem with installing
automake if we come to an agreement that we need to require it as
a build tool. I do have a problem with requirements creep happening
without discussion/consensus. For now, I'd like to see if we can
avoid needing automake...
regards, tom lane