From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
---|---|
To: | Roberto Costa <rob(dot)costa(at)libero(dot)it> |
Cc: | PostgreSQL interfaces mailing list <pgsql-interfaces(at)postgresql(dot)org> |
Subject: | Re: Automatic detection of PostgreSQL version |
Date: | 2003-03-12 00:35:11 |
Message-ID: | Pine.LNX.4.44.0303120121460.1617-100000@peter.localdomain |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)gmx(dot)net
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2003-03-12 00:35:18 | Re: Postgres Scaling |
Previous Message | Peter Eisentraut | 2003-03-12 00:34:55 | Re: permanently setting PROMPT1 |