Обсуждение: Building in a different directory

I sent a message along these lines yesterday, but never saw a copy.
Apologies if this is a repeat.

I normally prefer to build packages in directory other than the source
directory.  When I get a package, I normally do something like this:
    tar -xzvf foo-1.0.tar.gz
    mkdir foo-objdir
    cd foo-objdir
    ../foo-1.0/configure
    make

This is supported by autoconf in conjunction with GNU make.

Is there any interest in changing Postgres to support this?  The main
change is to rename a lot of Makefile files to Makefile.in, add a
couple of lines to each Makefile.in, and add the new Makefile.in files
to the list in AC_OUTPUT in configure.

For that matter, is there any interest in converting Postgres to use
automake?  Using automake, you write Makefile.am files instead of
Makefiles.  Makefile.am files are generally much smaller than
Makefiles, and automake also provides a number of convenient features
such as automatic dependency tracking.  However, it is a shift in
paradigm, and as such requires support from the developer community
(for one thing, any developer who needs to modify a Makefile needs to
install a copy of automake).  I've automakified complex packages in
the past, and I believe it's entirely doable for Postgres.

Is this the right mailing list to discuss this issue?

Ian

Ian Lance Taylor writes:

> I normally prefer to build packages in directory other than the source
> directory.

This is supported by the development branch since last week.

> For that matter, is there any interest in converting Postgres to use
> automake?

The last time we thought about this we quickly rejected it.  A couple of
reasons:

* We don't want to sit and wait for config.status to finish writing its
200+ Makefile's, when we can get away with writing two or three and have
the rest include them.

* Automake requires using libtool, and libtool doesn't satisfy our needs
yet.

* Automake doesn't handle building Perl, Python, Tcl, Java code very well.

* Automake doesn't handle our documentation format.

* Automake is in many ways too insistent on the GNU standards for our
taste.

I don't see what it would buy us at this point.

> Is this the right mailing list to discuss this issue?

Generally, we discuss development on pgsql-hackers.

--
Peter Eisentraut      peter_e@gmx.net       http://yi.org/peter-e/

   Date: Sat, 28 Oct 2000 16:24:19 +0200 (CEST)
   From: Peter Eisentraut <peter_e@gmx.net>

   Ian Lance Taylor writes:

   > I normally prefer to build packages in directory other than the source
   > directory.

   This is supported by the development branch since last week.

Cool.

   > For that matter, is there any interest in converting Postgres to use
   > automake?

   The last time we thought about this we quickly rejected it.  A couple of
   reasons:

   * We don't want to sit and wait for config.status to finish writing its
   200+ Makefile's, when we can get away with writing two or three and have
   the rest include them.

Fair enough.

   * Automake requires using libtool, and libtool doesn't satisfy our needs
   yet.

This turns out not to be the case.  libtool is independent of
automake.

   * Automake doesn't handle building Perl, Python, Tcl, Java code very well.

I've used it for Perl, Tcl and Java.  It doesn't provide much
automatic support.  But you can just keep the existing rules.

   * Automake doesn't handle our documentation format.

Again, you can just keep the existing rules.

   * Automake is in many ways too insistent on the GNU standards for our
   taste.

automake doesn't really insist on things, as I see it.  The defaults
are certainly for the GNU standards.  But it's fairly easy to use it
in other ways.

In any case, I think that following the GNU standards need not be a
bad thing.  It makes the system more familiar to other developers, and
thus makes it easier for them to contribute.  But that is just my
opinion--and I've been using the GNU standards for many years, so I am
clearly biased.

   I don't see what it would buy us at this point.

OK.

   Generally, we discuss development on pgsql-hackers.

OK, thanks.  The mailing list description on
    http://www.postgresql.org/mhonarc/pgsql-admin/
led me to think that this was the right list.  But I probably just
misread it.

Ian