[Libpqxx-general] Problem with the tests using Visual Studio 2008 and libpqxx version 3.0

[Jeroen Vermeulen]

Andrew Maclean wrote:
> Firstly I built version 3.0 of libpqxx and postgresql 8.3.5 with no
> problems following the instructions using Visual Studio 2008.
> However when running the tests the nmake file does not work. I note
> that there is a ticket for this problem. Make clean also needs to be
> fixed in this file too.

Hello Andrew,

It looks like the problem was with omitted directory names.  I submitted 
what I hope is a fix for it yesterday.

So have you tried the version in the 2009-01-06 snapshot (or later, if 
you read this later) from https://pqxx.org/~jtv/tmp/pqxx/snapshot?

Of course I'd be glad to have CMake files as well, but since there's a 
make with the compiler distribution, I'd like to focus on getting the 
regular Makefiles right first!

Also, Kirit Saelensminde is working on a set of project files for Visual 
C++ to enable builds from the IDE, and to make it easy to set up a 
project of your own using libpqxx.


> The debug, static version of all the tests will build Ok.
> The release, static version will build but not run.
> If you select debug or release, dynamic build then the following
> linker errors arise for tests
> 046,067,069,070,072,073,074,075,084,087,088,092:
> 
> error LNK2019: unresolved external symbol "void __cdecl
> pqxx::internal::throw_null_conversion(class
> std::basic_string<char,struct std::char_traits<char>,class
> std::allocator<char> > const &)"
> (?throw_null_conversion at internal@pqxx@@YAXABV?$basic_string at DU?$char_traits at D@std@@V?$allocator at D@2@@std@@@Z)
> referenced in function "public: static bool __cdecl
> pqxx::string_traits<bool>::null(void)" (?
> null@?$string_traits at _N@pqxx@@SA_NXZ)

Looks like a missing PQXX_LIBEXPORT.  I've added that for both 3.0.1 and 
3.1.

Hope it won't cause any ABI incompatibilities between 3.0.0 and 3.0.1, 
but we live and learn.  :)


> As an aside. we develop for Linux 32/64-bit, XP, Vista, QNX using many
> different compilers. So whilst not enforcing the use of CMake it
> became apparent that this was the only efficient way to undertake
> cross-platform development. Most of our people use CMake and they
> generally undergo a conversion from automake tools when discovering
> that their code won't compile easily in Windows! Along with CMake we

A CMake build setup has been on my wish list for a long time, but as I 
recall, two things made me give up.  One was that the documentation was 
woefully inadequate at the time.  The other may have been a consequence 
of the first: it was not clear to me what to do with all the 
configuration items in configure.ac.in.  It's not going to fly unless I 
can keep using that without substantial changes.


> use CTest so that when a developer submits code to the subversion
> repository CTest detects this and the code is tested on all platforms
> within 10 minutes of submission. Thus we detect errors relatively
> quickly. CMake is also tested in the same way, look at the dashboard
> for it.

I wish I had such a test farm for libpqxx.  Unfortunately I'm more or 
less limited to a single lightweight server that runs the test suite 
once a day.  It's pretty intense as it goes through multiple compilers, 
postgres backend versions, and libpq versions, so not something I could 
run on every commit.  When I have time (...) I'd like to see about EC2.


> The two files FindPostgreSQL.cmake and FindLibpqxx.cmake were written
> by myself to make usage of your library simple.

This actually interests me more than building libpqxx itself!  Getting 
started with a libpqxx-using project is much too painful on Windows, 
from what I hear, so anything that makes it easier is welcome.

The hard-coded version numbers and drive letters and such for Windows do 
scare me though.  There must be a better way than to name these 
literally.  For postgres there's a script called pg_config that tells 
you everything about the postgres version it was installed with.  I 
think it'd be healthier to look for that script--although actually 
running it isn't exactly safe on Windows because there's no way of 
knowing where it came from.


Jeroen