I've found pg_config the best solution to determine where things are
installed.
"pg_config provides information about the installed version of PostgreSQL.
Usage: pg_config --bindir | --includedir | --includedir-server | --libdir |
--pkglibdir | --configure | --version
Operation modes:
--bindir show location of user executables
--includedir show location of C header files of the client
interfaces
--includedir-server show location of C header files for the server
--libdir show location of object code libraries
--pkglibdir show location of dynamically loadable modules
--configure show options given to 'configure' script when
PostgreSQL was built
--version show the PostgreSQL version and exit"
However, on that note, just "installing the darn module" may not be possible
without skipping the tests.
There are additional pieces of information needed:
$ENV{DBDPG_TEST_DB}
$ENV{DBDPG_TEST_HOST}
$ENV{DBDPG_TEST_USER}
$ENV{DBDPG_TEST_PASS}
(prevents mucking up a real database)
Other DBD::* modules require DBI_DSN, DBI_USER, DBI_PASS to run the
tests. Without the correct setup installing from CPAN will fail.
Tom
Report bugs to <[EMAIL PROTECTED]>.
On Sun, Nov 24, 2002 at 04:33:15PM -0600, Dave Rolsky wrote:
> On Sun, 24 Nov 2002, Randal L. Schwartz wrote:
>
> > Jason> Absolutely. It is one of the first things that was discussed. The
> > Jason> decision was to use App::Info during the configuration phase.
> >
> > Well, I hope it just falls back to doing the right thing if the lib
> > and include file are found in the same places Perl looks for
> > everything else.
> >
> > Don't ask questions. Just install the darn module.
>
> It looks for pg_config, which if found will tell it what it needs. I'd
> prefer that it ask questions rather than the current irritating approach
> of just giving up completely, though.
--
Thomas A. Lowery
See DBI/FAQ http://xmlproj.dyndns.org/cgi-bin/fom
