X-Original-To: pgsql-interfaces@postgresql.org Received: from gollum.gnome-db.org (69.Red-80-33-181.pooles.rima-tde.net [80.33.181.69]) by postgresql.org (Postfix) with ESMTP id 6ECD94758E6 for ; Wed, 12 Mar 2003 07:54:49 -0500 (EST) Received: from [192.168.0.3] (211.Red-80-59-90.pooles.rima-tde.net [80.59.90.211]) by gollum.gnome-db.org (Postfix) with ESMTP id BB54D37C115; Wed, 12 Mar 2003 13:54:50 +0100 (CET) Subject: Re: Automatic detection of PostgreSQL version From: Rodrigo Moya To: Peter Eisentraut Cc: Roberto Costa , PostgreSQL interfaces mailing list In-Reply-To: References: Content-Type: text/plain Message-Id: <1047473504.1016.28.camel@azkoyen.gnome-db.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.3.1.99 (Preview Release) Date: 12 Mar 2003 13:51:44 +0100 Content-Transfer-Encoding: 7bit X-Archive-Number: 200303/53 X-Sequence-Number: 3802 On Wed, 2003-03-12 at 01:35, Peter Eisentraut wrote: > Roberto Costa writes: > > > What I'm currently doing is searching typical include directories (like > > /usr/include, /usr/local/share/include, ...) for the presence of a > > directory named postgresql or pgsql that contains config.h or > > pg_config.h (used since PostgreSQL 7.2, if I'm not wrong). When such a > > file is found, I grep it for a line that starts with "#define > > PG_VERSION" and I expect the version follow and be in the form "x.y.z". > > This works for the latest PostgreSQL versions that I could test, > > however I don't know whether this check may work with earlier ones. In > > reality I even ignore if this kind of check is the best way to get what > > I want. > > All of that seems highly unusual. configure scripts are supposed to check > for alternative features in libraries, not search the entire file system > for the "best" library. I suggest you just include the libpq++ header > file in your code and be done with it. If it's missing the user will get > an error from the compiler and will know what to do. > well, many power users will know what to do, but a lot other users will not. So I guess a configure check and --with/--without arguments might be the correct way to do it. I myself have the following in my configure.in: dnl Test for PostgreSQL try_postgres=true AC_ARG_WITH(postgres, [ --with-postgres= use postgres backend in ],[ if test $withval = no then try_postgres=false elif test $withval = yes then dir="/usr/local" else dir=$withval fi ]) postgresdir="" if test $try_postgres = true then AC_MSG_CHECKING(for Postgres files) for d in $dir /usr /usr/local/postgres /opt/postgres /opt/packages/postgres /disk/postgres /usr/local/pgsql do if test -f $d/lib/libpq.so then AC_MSG_RESULT(found Postgres in $d) postgresdir=$d break fi done if test x$postgresdir = x then AC_MSG_WARN(Postgres backend not used) else if test -f ${postgresdir}/include/libpq-fe.h then POSTGRES_CFLAGS=-I${postgresdir}/include elif test -f ${postgresdir}/include/pgsql/libpq-fe.h then POSTGRES_CFLAGS=-I${postgresdir}/include/pgsql elif test -f ${postgresdir}/include/postgresql/libpq-fe.h then POSTGRES_CFLAGS=-I${postgresdir}/include/postgresql else AC_MSG_WARN(Postgres include files not found, backend not used) postgresdir="" fi POSTGRES_LIBS="-L${postgresdir}/lib -lpq" AC_DEFINE(HAVE_POSTGRES) fi fi AM_CONDITIONAL(POSTGRES, test x$postgresdir != x) thus, you can have your user specify which version of postgres she wants to compile against, by just using a --with-postgres=/dir/to/use cheers