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

[Andrew Maclean]

On Wed, Jan 7, 2009 at 6:12 AM, Jeroen Vermeulen <jtv at xs4all.nl> wrote:
> 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.  :)
>

Things seem to build Ok in debug mode but I am still having trouble in
release mode. If I get some time I will look further into it. I have
switched to using the subversion repository.


>
>> 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.
>

CMake will let you have a file like configure.h.in and depending upon
the cmake process it will configure a file called configure.h. Look at
http://www.cmake.org/Wiki/CMake, in particular
http://www.cmake.org/Wiki/CMake_HowToDoPlatformChecks. If you are
interested I have an example of this usage.

I agree that the documentation is somewhat opaque. You really need to
buy the book, but the Wiki is helpful. CMake also has an option to
print out an abbreviated list of commands and brief explanation. The
cmake user group is really usefull.

>
>> 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.

This is a constant problem on Windows (the drive names) if you look at
the CMake scripts, you can see that you can set an environment
variable LIBPQXX_ROOT to point to the root of the directory. Similarly
for FindPostgresql.cmake you can set the environment variable
POSTGRESQL_ROOT. If these are set, FindLibpqxx and FindPostgresql will
use these in preference to searching. A lot of the FindXXX scripts on
the modules subdirectory of CMake do this too.


>
>
> Jeroen
> _______________________________________________
> Libpqxx-general mailing list
> Libpqxx-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/libpqxx-general
>

Regards
   Andrew



-- 
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney  2006  NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________