[Libreoffice] postresql-sdbc bits out of minutes of tech. steering call

[Lionel Elie Mamane]

On Thu, Dec 08, 2011 at 04:19:04PM +0000, Michael Meeks wrote:

> * postgresql fun. non-internal
> 	+ postgresql have a strict API stability (Norbert)

Norbert was saying they have a strict *ABI* stability, properly
managing sonames and all that. I'm not sure if MS Windows has a
mechanism that gives the same functionality of "marking
ABI-incompatible versions as such", but
http://en.wikipedia.org/wiki/DLL_Hell suggests they do not. In this
case, we absolutely cannot rely on the users installing libpq
separately, beyond the problems mentioned by Fridrich.

> 	+ Windows - run-time DLL dependency a pain (Lionel)
> 		+ ship DLL ourselves ?

This is not a question mark, we have to do that, or link statically,
be it only because of Fridrich-mentioned problems.

Note that currently postgresql-sdbc always links statically when using
internal PostgreSQL. It links dynamically with system PostgreSQL, and
does not ship the dynamic library itself. The latter is typically what
GNU/Linux distributions want: the package will have a dependency on
the right dynamic library. Is that what we want for our downloads from
http://www.libreoffice.org/download/ ? Maybe not, I notice that the
.deb files we distribute declare no other dependency than between
themselves.

> 	+ building vs. an internal libpostgresql (Lionel)
> 		+ client library code is:
> 			+ around 25 files + a few headers
> 		+ can knock up a gnumake makefile in a module
> 		  as a static library.

So, the situation with Windows is a bit more flexible than what I
previously reported, but that is not necessarily helpful to
us. PostgreSQL on Windows can be built in more ways than I knew:

 - ActiveState Perl and MSVC: no go, we'd like not to require
   ActiveState Perl as a build dependency
   http://www.postgresql.org/docs/9.1/static/install-windows-full.html

 - MinGW: would requiring MinGW/MSYS as a build dependency be any
          better than requiring ActiveState Perl? I understand this
	  build does not need any piece MinGW/MSYS at run-time (like
	  Cygwin would), and I guess it is binary-compatible with
	  MSVC-compiled code? I mean we compile only libpq with MinGW,
	  the rest of LibO with cygwin-bash/awk/... driving MSVC and
	  it all works out?
   http://www.postgresql.org/docs/9.1/static/installation-platform-notes.html#INSTALLATION-NOTES-MINGW

 - Cygwin: Tor explained this is not useful

 - Borland C++ / old MSVC: not useful

 - knock up our own Makefile for the subpart we need: more fragile wrt
   to new versions of PostgreSQL (may need to update that makefile);
   but possibly still the easiest solution.


-- 
Lionel