Re: Automatic detection of PostgreSQL version
От | Peter Eisentraut |
---|---|
Тема | Re: Automatic detection of PostgreSQL version |
Дата | |
Msg-id | Pine.LNX.4.44.0303121628250.1643-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Re: Automatic detection of PostgreSQL version (Rodrigo Moya <rodrigo@gnome-db.org>) |
Список | 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 по дате отправления: