Hi Vadim,
I'm sorry to heard that you were using SOCI without CMake, I was
absolutely sure that everybody was using SOCI as an external dependency.
Mateusz already answer about the reasons.
But I disagree having macro named SOCI_HAVE_CONFIG_H. That means that
everyone using SOCI will have to define this macro. I prefer to have
SOCI_HAVE_NO_CONFIG_H, or maybe SOCI_NO_CMAKE will be more meaningful
and specific for people using custom build systems.
Arnaud
On 27/01/2016 21:15, Mateusz Loskot wrote:
On 27 January 2016 at 18:21, Vadim Zeitlin<vz-s...@zeitlins.org> wrote:
I've somehow missed the commits 6908e473ff2da566d335f23015b971c7f2118239
and 094e19c68c0c98cfc862bb316868552a7443d145, but trying to use the latest
SOCI version in our code now, I realize that it's a problem to have
soci-config.h and version.h to be generated by cmake for us because we
can't build SOCI any longer simply using our own make/project files as we
always did so far.
Vadim,
Sorry for the trouble.
IMHO it never was a problem in practice to specify SOCI_HAVE_BOOST and I
don't really see what do we gain from having it in a generated file instead
of on the command line,
The reason is to free developers from manual synchronisation
of client build configurations according to features built into SOCI binaries
(e.g. installed form the binary packages).
Since optional features are part of public interface (headers),
it is obvious choice to keep headers and binaries in sync,
so clients can rely on headers only.
but I could live with it if we also had something
like SOCI_HAVE_CONFIG_H that would be tested before including this file as
this would still allow me to compile the sources directly as before. Would
there be any objections to doing this?
No objection.
As for version.h, I just don't see what's the benefit of generating it at
all... Could someone (Arnaud?) please explain it or could we perhaps just
revert 094e19c68c0c98cfc862bb316868552a7443d145?
Arnaud discovered that we had version defined in two places, so he
removed the redundant definition, what is good.
He simply chose to use the value defined in CMake (PR #436).
As long as SOCI uses CMake as default builder, I'm not concerned about
custom user-defined build configurations. So, I merge such contributions
without objections. Alternative solutions are welcome too, if provided.
Best regards,
------------------------------------------------------------------------------
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
soci-devel mailing list
soci-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/soci-devel
