Thread

1. Configuration and build clean-up

   Peter Eisentraut <peter_e@gmx.net> — 2000-05-29T17:11:38Z

   As an on-going process starting now I would like to begin cleaning up the
   configuration and build process, in particular to eventually have
   
   * Separate build directory
   
   * Automatic dependency tracking
   
   * Semi-automatic packaging
   
   as well as to
   
   * Remove a number of hacks, bogosities, and faults
   
   * Be ready for the next Autoconf release, coming soon
   
   but most of all to
   
   * Make life easier for users and developers
   
   Changes will mostly be internal but to get most of this to work okay the
   configure script really needs to live in the top level directory of the
   package.
   
   Rationale:
   
   - This is where users expect it and everyone else has it.
   
   - Separate build directories will behave more sensical.
   
   - Would be nice if a top level makefile took care of the documentation
   build and install as well.
   
   - Automated packaging will really not work otherwise.
   
   In order to not clutter the top level directory with stuff such as
   `config.guess', I suggest making a separate directory `config/' where to
   put all these things (incl. install-sh, mkinstalldirs, etc.), as there
   will probably be more as we go along.
   
   This layout is recommended by the Autoconf maintainers, btw.
   
   Any objections to this point?
   
   
   -- 
   Peter Eisentraut                  Sernanders väg 10:115
   peter_e@gmx.net                   75262 Uppsala
   http://yi.org/peter-e/            Sweden
   
   
   

2. Re: Configuration and build clean-up

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-29T18:10:19Z

   Peter Eisentraut <peter_e@gmx.net> writes:
   > [ much good stuff ]
   
   > - Would be nice if a top level makefile took care of the documentation
   > build and install as well.
   
   Yeah.  The doc makefile already depends on configure having been run,
   and it's just plain weird that it's reaching over to a sibling directory
   instead of being configured by a configure script above it.
   
   > - Automated packaging will really not work otherwise.
   
   What do you mean by automated packaging?
   
   > Any objections to this point?
   
   All the specifics sound good to me.  One thing to watch out for is that
   we will probably still need something comparable to the current setup's
   "template" mechanism to select system-specific hints (like which tas()
   implementation to use).  Overall there is a lot of painstaking
   portability work embodied in the current setup; don't throw the baby out
   with the bathwater while you're trying to make us fully Autoconf-ish.
   
   I didn't notice anything about libtool in your list of items, but
   I should think that replacing Makefile.shlib with libtool would be
   a much better way of handling the various client shlibs.  Is that
   part of your plan?
   
   BTW, I cleaned out a few Makefile bogosities yesterday, so be sure you
   are starting from current sources.
   
   			regards, tom lane
   
   

3. Re: Configuration and build clean-up

   Trond Eivind Glomsrød <teg@redhat.com> — 2000-05-29T18:59:26Z

   Peter Eisentraut <peter_e@gmx.net> writes:
   
   > As an on-going process starting now I would like to begin cleaning up the
   > configuration and build process, in particular to eventually have
   
   If so, please fix this in the configure.in script:
   
   AC_CONFIG_AUX_DIR(`pwd`)
   
   This doesn't work very well with libtool:
   
   [root@hoser src]# libtoolize 
   Remember to add `AM_PROG_LIBTOOL' to `configure.in'.
   Using `AC_PROG_RANLIB' is rendered obsolete by `AM_PROG_LIBTOOL'
   You should add the contents of `/usr/share/aclocal/libtool.m4' to `aclocal.m4'.
   Putting files in AC_CONFIG_AUX_DIR, ``pwd`'.
   /usr/bin/libtoolize: `pwd`: Ingen slik fil eller filkatalog
   [root@hoser src]#
   
   libtoolize (a part of libtool) isn't important on int's own, but it's
   used as part of some automated buildsystems 
   
   -- 
   Trond Eivind Glomsrød
   Red Hat, Inc.
   
   

4. Re: Configuration and build clean-up

   Peter Eisentraut <e99re41@docs.uu.se> — 2000-05-30T10:04:10Z

   On Mon, 29 May 2000, Tom Lane wrote:
   
   > What do you mean by automated packaging?
   
   make dist, integrating the release_prep thing into the makefiles.
   Something like make rpm-spec would eventually be nice as well.
   
   > One thing to watch out for is that we will probably still need
   > something comparable to the current setup's "template" mechanism to
   > select system-specific hints (like which tas() implementation to use).  
   
   Yes, there's really no way around keeping that.
   
   > I didn't notice anything about libtool in your list of items,
   
   The problem with libtool is this: it can't handle multiple languages at
   once. That means that you'd have to build libpq and libpq++ with
   sufficiently similar compilers. I guess this is how it is already but at
   least it would have to be carefully evaluated. One option would be to use
   libtool for all C stuff and keep the current funny business for libpq++,
   or we could volunteer as earlier testers for libtool's multi-language
   branch. All in all it looks like a separate undertaking.
   
   
   -- 
   Peter Eisentraut                  Sernanders väg 10:115
   peter_e@gmx.net                   75262 Uppsala
   http://yi.org/peter-e/            Sweden
   
   
   

5. Re: Configuration and build clean-up

   Tom Lane <tgl@sss.pgh.pa.us> — 2000-05-30T14:22:39Z

   Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
   >> I didn't notice anything about libtool in your list of items,
   
   > The problem with libtool is this: it can't handle multiple languages at
   > once. That means that you'd have to build libpq and libpq++ with
   > sufficiently similar compilers.
   
   Hmm.  The one thing that we really need libtool for is to deal with
   cross-shlib dependencies --- eg, arranging for libpq.so to be pulled
   in if libpq++.so is loaded.  (Right now, at least on my platform,
   this doesn't work... the client app has to mention both at link time.)
   I think we could assume that all the files in any one shlib are compiled
   with the same compiler; is that enough, or does it still fall over?
   
   The main place where I'm concerned about "only one compiler" is in pltcl
   and plperl.  We have found that the most reliable way to build those is
   with the compiler and switches that were used to build Tcl and Perl
   respectively, not with the compiler/switches being used for the main
   Postgres build.  One of the bits we have painstakingly got right is to
   make this actually work (last time I tried, I could build these with
   HP's cc whilst Postgres was configured with gcc or vice versa).  The
   simplest answer for those two might be to leave well enough alone.
   There's no real reason to libtoolize them that I can see, nor to try
   to fold them into a unified Postgres build environment.
   
   			regards, tom lane