Обсуждение: Automatic detection of PostgreSQL version
Hello, I'm starting an open-source project, which will include a client to access a PostgreSQL database through libpq++ library. I'm quite new to PostgreSQL and I haven't followed its development, this is why I hope to find some information I need here! For the configure.ac file of the above mentioned project, I would like to use an autoconf macro to detect the location of PostgreSQL's include directory eventually installed on the system and, if more than one are found, to select the most recent (by default). I looked over the internet to see whether such a macro is already available somewhere, I couldn't find it and I began writing my own one. 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. What do you think about that? Do you know where I could find the information I'm looking for? Any suggestion, comment or remark is more than welcome! Cheers, Roberto
Roberto Costa <rob.costa@libero.it> 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 requires that the Postgres include files be installed, which seems
an unreliable bet to me. It'd be better to look for the executable
pg_config and run "pg_config --version". If you find multiple
pg_config's, you can select the most preferable version. After that,
you can ask pg_config where the include and library files are supposed
to be.
One advantage of doing it this way is that it should be sufficient to
look in the $PATH directories, rather than searching some ad-hoc
collection of likely include locations.
regards, tom lane
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. (Possibly there will be some documentation to help him, too.) Users that have multiple versions installed can select the one to use with the usual CPPFLAGS and LDFLAGS variables. -- Peter Eisentraut peter_e@gmx.net
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=<directory> use postgres backend in <directory>],[
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
notused) 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
includefiles 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
Rodrigo Moya writes: > 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: Personally, I don't see much conceptual difference between running configure --with-postgresql=/foo and configure CPPFLAGS=-I/foo/include LDFLAGS=-L/foo/lib except that the second is the standard way. (Admittedly, it's also a bit uglier.) And both need to be documented anyway. If you still want to go that route I recommend to you to inspect the configure script of OSDB (osdb.sf.net). (I recommend it because I wrote it. ;-) ) Since it lies in the nature of OSDB that you may want to run it against one of several installed versions of PostgreSQL, it seems appropriate to offer the choice. But if you're just writing a normal user-level application then you need not go there. Maybe check what PHP is doing. GNU Gettext has also put a fair amount of thought into the problem of finding external libraries (libiconv in that case). They offer some prebaked macros that you might find useful. I personally don't care much for them. Keep in mind that if your package requires more than one external library, it is essential that the user can configure the compiler search paths manually, to be able to cope with unusual installation patterns. Regarding your patch, test -f libpq.so is not an appropriate way to check for a library (since the name doesn't always have to be libxxx.so). Call the linker to check for libraries. -- Peter Eisentraut peter_e@gmx.net