Thread: Re: Gripe: working on configure now requires Automake installed locally

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