Horton

Thread

  1. Gripe: working on configure now requires Automake installed locally

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-11T20:02:03Z

    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

  2. Re: Gripe: working on configure now requires Automake installed locally

    Peter Eisentraut <peter_e@gmx.net> — 2000-06-11T22:44:44Z

    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

  3. Re: Gripe: working on configure now requires Automake installed locally

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-12T14:50:46Z

    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

  4. Re: Gripe: working on configure now requires Automake installed locally

    Peter Eisentraut <e99re41@docs.uu.se> — 2000-06-13T12:38:39Z

    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

  5. Re: Re: Gripe: working on configure now requires Automake installed locally

    Marc G. Fournier <scrappy@hub.org> — 2000-06-15T12:00:27Z

    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?

  6. Re: Re: Gripe: working on configure now requires Automake installed locally

    Peter Eisentraut <peter_e@gmx.net> — 2000-06-15T16:22:15Z

    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

  7. Re: Re: Gripe: working on configure now requires Automake installed locally

    Tom Lane <tgl@sss.pgh.pa.us> — 2000-06-15T23:40:31Z

    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