[Libpqxx-general] suggestion for more flexibility with win32 complilation process

[Matthew Pugsley]

Hello all,

OS: Vista - 32 bit
Compiler/IDE: Visual C++ 2008
Postgres: Using 8.3, installed using their 'one-click' msi installer.
Background music: "Smooth Criminal" by Michael Jackson
Beverage: Seabreeze
http://en.wikipedia.org/wiki/Sea_breeze_(cocktail)<http://en.wikipedia.org/wiki/Sea_breeze_(cocktail>


Suggestion/request: For the Win32 compilation process (for Visual C++), edit
the files 'common-sample', 'vc-libpqxx.mak', and 'vc-libqxx.mak.template' so
that they are less dependent upon directory structure. The instructions
recommend compiling Postgres from source. If this is done, I expect that the
directory structure will be what is expected by the three files I mentioned.
But I have already installed Postgres using their msi 'one-click' installer.
It appears to already have libpq support since it has the relevant files and
directories. The problem is that the directory structure is quite different,
which causes problems when using the make files for libpqxx.

Issues:
1.  The current make file assumes that I am using foward slashes (as it
appends '/include' to $(PGSQLSRC) in the section "# The options common to
all the different builds"). I need a backslash. If we were allowed (and
expected) to specify the full path in the 'common' file, both
forward-slashers and back-slashers would be satisfied, as we would define
the full path in the manner we needed.
2.  The make file concatenates the incorrect directories for my situation.
(Would be fixed if I could specify what is needed in the 'common' file.) It
looks for things like "$(PGSQLSRC)\interfaces\libpq\release\libpq.dll" when
copying and and include paths like "/I $(PGSQLSRC)/interfaces/libpq" when I
need something entirely different because my include directory and my binary
directory are side by side in my Postgres installation:

C:\Program Files\PostgreSQL\8.3\include
C:\Program Files\PostgreSQL\8.3\bin

(Side question: Even if I wanted a '/include' appended to $(PGSQLSRC),
wouldn't the value of PGSQLSRC need to *not* have quotation marks?)

So you see that I can't use relative path of ./interfaces/libpq to get to
the binary. If I specify the path needed in each case (as a whole), then I
would avoid issues 1 and 2 above. This could be useful even for those
building from Postgres source. The directory structure of that source could
change someday. If so, the assumptions made in the make file (or template
rather), would be incorrect even for that situation.

Different but related suggestion:
Make the copying of libpqd.dll conditional on whether the user has a debug
version of this dll file. The user could specify this with a "YES" or "NO"
value for some value (such as HAS_DEBUG). That way, those folks with only
the release version (like me, because I didn't compile Postgres from source)
won't have to comment out this code in the make file/template.

I'm still hacking around with the files, trying to make adjustments needed
to suit my conditions. I have been unsuccessful so far. I'm now getting
errors about make 'not knowing how to make libpqd.dll'. If I'm successful,
I'll report back on what I needed to change. If not, I'll compile Postgres
from source.

Best,
Matt Pugsley


-- 
matthew.pugsley at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://pgfoundry.org/pipermail/libpqxx-general/attachments/20090301/052980af/attachment.html