Discussion:
[soci-users] How to set include directories selectively with CMake?
Vadim Zeitlin
2015-03-31 20:50:18 UTC
Permalink
Hello,

I've installed DB2 headers and libraries to be able to test that DB2
backend at least compiles (I still can't check whether it works because I
don't have access to any DB2 database server) and discovered that this
breaks the build of the ODBC backend as there is a conflict between
sqlext.h in DB2 include directory and ODBC file with the same name in
/usr/include. I.e. currently it seems to be impossible to build both DB2
and ODBC backends.

A straightforward fix would be to only use DB2_INCLUDE_DIR when compiling
DB2 files (the backend itself and the test), but I have no idea about how
to do this with CMake. Could any CMake experts please help?

TIA,
VZ
Mateusz Loskot
2015-04-14 07:55:32 UTC
Permalink
Post by Vadim Zeitlin
Hello,
I've installed DB2 headers and libraries to be able to test that DB2
backend at least compiles (I still can't check whether it works because I
don't have access to any DB2 database server) and discovered that this
breaks the build of the ODBC backend as there is a conflict between
sqlext.h in DB2 include directory and ODBC file with the same name in
/usr/include. I.e. currently it seems to be impossible to build both DB2
and ODBC backends.
Sounds like a little mess in CMake configuration.
Presumably, you've already fixed that in
https://github.com/SOCI/soci/pull/313

Thanks!

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Vadim Zeitlin
2015-04-14 12:05:42 UTC
Permalink
On Tue, 14 Apr 2015 09:55:32 +0200 Mateusz Loskot <***@loskot.net> wrote:

ML> On 31 March 2015 at 22:50, Vadim Zeitlin <vz-***@zeitlins.org> wrote:
ML> > Hello,
ML> >
ML> > I've installed DB2 headers and libraries to be able to test that DB2
ML> > backend at least compiles (I still can't check whether it works because I
ML> > don't have access to any DB2 database server) and discovered that this
ML> > breaks the build of the ODBC backend as there is a conflict between
ML> > sqlext.h in DB2 include directory and ODBC file with the same name in
ML> > /usr/include. I.e. currently it seems to be impossible to build both DB2
ML> > and ODBC backends.
ML>
ML> Sounds like a little mess in CMake configuration.
ML> Presumably, you've already fixed that in
ML> https://github.com/SOCI/soci/pull/313

Yes, this turned out to be simpler than I thought. But I still marvel at
how people can like CMake...

BTW, it's a small thing but it was still nice that several fewer mouse
clicks were required when making this PR 133 as master is now the default
branch. Thanks for your work on this!
VZ
Mateusz Loskot
2015-04-14 14:53:50 UTC
Permalink
Post by Vadim Zeitlin
ML> > Hello,
ML> >
ML> > I've installed DB2 headers and libraries to be able to test that DB2
ML> > backend at least compiles (I still can't check whether it works because I
ML> > don't have access to any DB2 database server) and discovered that this
ML> > breaks the build of the ODBC backend as there is a conflict between
ML> > sqlext.h in DB2 include directory and ODBC file with the same name in
ML> > /usr/include. I.e. currently it seems to be impossible to build both DB2
ML> > and ODBC backends.
ML>
ML> Sounds like a little mess in CMake configuration.
ML> Presumably, you've already fixed that in
ML> https://github.com/SOCI/soci/pull/313
Yes, this turned out to be simpler than I thought. But I still marvel at
how people can like CMake...
I wouldn't say I like it, but it was the easiest multi-platform
non-Autotools builder
was able wrap my head around, with single-click installation on every OS
and no third-party dependencies itself.

One of problems is that SOCI started using CMake before it received some cool
features that clean things up (better scopes, object libraries, etc.).
So, there is a legacy of hacks that should be cleaned up over time.
Post by Vadim Zeitlin
BTW, it's a small thing but it was still nice that several fewer mouse
clicks were required when making this PR 133 as master is now the default
branch. Thanks for your work on this!
Actually, I'm glad you raised that issue and we've switched to the simpler flow.

Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Loading...