pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedAutomatic detection of PostgreSQL version
5+ messages / 4 participants
[nested] [flat]
* Automatic detection of PostgreSQL version
@ 2003-03-10 21:10 Roberto Costa <rob.costa@libero.it>
2003-03-10 21:31 ` Re: Automatic detection of PostgreSQL version Tom Lane <tgl@sss.pgh.pa.us>
2003-03-12 00:35 ` Re: Automatic detection of PostgreSQL version Peter Eisentraut <peter_e@gmx.net>
0 siblings, 2 replies; 5+ messages in thread
From: Roberto Costa @ 2003-03-10 21:10 UTC (permalink / raw)
To: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Automatic detection of PostgreSQL version
2003-03-10 21:10 Automatic detection of PostgreSQL version Roberto Costa <rob.costa@libero.it>
@ 2003-03-10 21:31 ` Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 0 replies; 5+ messages in thread
From: Tom Lane @ 2003-03-10 21:31 UTC (permalink / raw)
To: Roberto Costa <rob.costa@libero.it>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Automatic detection of PostgreSQL version
2003-03-10 21:10 Automatic detection of PostgreSQL version Roberto Costa <rob.costa@libero.it>
@ 2003-03-12 00:35 ` Peter Eisentraut <peter_e@gmx.net>
2003-03-12 12:51 ` Re: Automatic detection of PostgreSQL version Rodrigo Moya <rodrigo@gnome-db.org>
1 sibling, 1 reply; 5+ messages in thread
From: Peter Eisentraut @ 2003-03-12 00:35 UTC (permalink / raw)
To: Roberto Costa <rob.costa@libero.it>; +Cc: pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Automatic detection of PostgreSQL version
2003-03-10 21:10 Automatic detection of PostgreSQL version Roberto Costa <rob.costa@libero.it>
2003-03-12 00:35 ` Re: Automatic detection of PostgreSQL version Peter Eisentraut <peter_e@gmx.net>
@ 2003-03-12 12:51 ` Rodrigo Moya <rodrigo@gnome-db.org>
2003-03-12 15:44 ` Re: Automatic detection of PostgreSQL version Peter Eisentraut <peter_e@gmx.net>
0 siblings, 1 reply; 5+ messages in thread
From: Rodrigo Moya @ 2003-03-12 12:51 UTC (permalink / raw)
To: Peter Eisentraut <peter_e@gmx.net>; +Cc: Roberto Costa <rob.costa@libero.it>; pgsql-interfaces
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 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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Automatic detection of PostgreSQL version
2003-03-10 21:10 Automatic detection of PostgreSQL version Roberto Costa <rob.costa@libero.it>
2003-03-12 00:35 ` Re: Automatic detection of PostgreSQL version Peter Eisentraut <peter_e@gmx.net>
2003-03-12 12:51 ` Re: Automatic detection of PostgreSQL version Rodrigo Moya <rodrigo@gnome-db.org>
@ 2003-03-12 15:44 ` Peter Eisentraut <peter_e@gmx.net>
0 siblings, 0 replies; 5+ messages in thread
From: Peter Eisentraut @ 2003-03-12 15:44 UTC (permalink / raw)
To: Rodrigo Moya <rodrigo@gnome-db.org>; +Cc: Roberto Costa <rob.costa@libero.it>; pgsql-interfaces
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
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2003-03-12 15:44 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2003-03-10 21:10 Automatic detection of PostgreSQL version Roberto Costa <rob.costa@libero.it>
2003-03-10 21:31 ` Tom Lane <tgl@sss.pgh.pa.us>
2003-03-12 00:35 ` Peter Eisentraut <peter_e@gmx.net>
2003-03-12 12:51 ` Rodrigo Moya <rodrigo@gnome-db.org>
2003-03-12 15:44 ` Peter Eisentraut <peter_e@gmx.net>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox