Re: Automatic detection of PostgreSQL version - Mailing list pgsql-interfaces

From Peter Eisentraut
Subject Re: Automatic detection of PostgreSQL version
Date
Msg-id Pine.LNX.4.44.0303121628250.1643-100000@peter.localdomain
Whole thread Raw
In response to Re: Automatic detection of PostgreSQL version  (Rodrigo Moya <rodrigo@gnome-db.org>)
List 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



pgsql-interfaces by date:

Previous
From: Christoph Haller
Date:
Subject: Re: Embedded C SQL Error -600
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] Roadmap for FE/BE protocol redesign