C++17 conflict with library

[lighta]

include/pqxx/tuple.hxx:95:33: error: ISO C++1z does not allow dynamic exception specifications reference at(size_type) const throw (pqxx::range_error); //[t11]

So the c++-17 seem quite an issue with the dynamic exception specifications removed cf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0003r5.html

[elelel]

What is the version of libpqxx library you are using? It does not seem to contain file tuple.hxx in my version (5.1.0). If you are using a conservative Linux distro (like Debian) it may contain an outdated version in packages. In this case you can clone it from here: https://github.com/jtv/libpqxx and point CMake accordingly.

[lighta]

yes I'm adding it as a submodule currently. My current version is : 4.0.1. My distro is fedora27. I'll update the cmake find_package to set the min version to 5.1 then

[elelel]

I don't think that 5.1 is really the min version. It's a fairly recent version (I use Archlinux and usually it has newer versions than in other distros), and pqxx does not have tuple.hxx at least since 2015. I suspect they removed it after c++11 has been adopted, which has std::tuple. So if you mean setting the min version to 5.1 in CMakeFiles.txt as a PR I think it will be too high for most people.

[lighta]

We could lower it afterwards, archlinux is quite uptodate with their bleeding-edge branch so I'm not surprise. Right now I didn't found where you search for libpqxx I just saw

if (NEED_FIND_PACKAGE_LIBPQXX_INCLUDE_DIRS)
    set(ARES_POSTGRES_INCLUDE_DIRS "${ARES_POSTGRES_INCLUDE_DIRS} ${PQXX_INCLUDE_DIRECTORIES}")
  endif()

I suppose if I wanted to do what I wanted I'd need to add a findLibpqxx.cmake as well

[elelel]

libpqxx's headers are supposed to be in system's include or specified manually. So I don't search for it manually anywhere, neither restrict the version. The reason why I just didn't make it as a git submodule as with other libraries is that it depends on libpq, which in turn is a pain to link against on Windows. So I leave it for the user to choose which version to use (it has to be compatible with libpq).

Correction: in fact it's a compiled library so I wouldn't be able to just add it as submodule

[elelel]

The problem with throw specifiers was fixed on Mar 24, 2012 by this commit: https://github.com/jtv/libpqxx/commit/ce486d16e3be71f9e81c6004edf0e633ad11ec6e#diff-540a154623ed528b7e62b809d2fee216 I don't know what release version it is, since release tags for libpqxx were introduced on github only since 5.0 and it's fairyl older than 5.0, but at least we know that 5.0 will do

[lighta]

Usually what I do for this is. option dependancyX => submodule or system. Then if submodule you fetch and compile else you use system. In both case for cmake it doesn't change much you still check for the headers and libraries it just the path that differ. (if it not found it propose to set the correct path)

(Granted it's not done in rA yet due to windows user always complaining..) For the libpqxx yeah I had the same issue as the github history wasn't full. will check the old one.