On Thu, 28 Jan 2016 10:51:18 +0100 adesmier <arn...@desmier.fr> wrote:
a> I'm sorry to heard that you were using SOCI without CMake, I was a> absolutely sure that everybody was using SOCI as an external dependency. Hello, I don't think I'm the only one, I remember reading some posts here (or on soci-users) from someone else not using CMake neither. And, even if we do something slightly different, I think it's pretty nice to just be able drop the SOCI files in your MSVS/XCode/whatever project directly, these changes break that. a> Mateusz already answer about the reasons. Yes, indeed (thanks Mateusz!), and I started writing a reply to that message but, as I'm already replying to this one and to avoid forking this thread, let me reproduce the salient points here: On Wed, 27 Jan 2016 21:15:55 +0100 Mateusz Loskot <mate...@loskot.net> wrote: ML> Arnaud discovered that we had version defined in two places, so he ML> removed the redundant definition, what is good. I partially agree with this, but I'm not sure if it's worth the trouble. First of all, this is not the only place where the version number is used, a quick git grep shows it's also in appveyour.yml and docs/installation.md and I could have missed it somewhere else. And changing the version is always at least a partly manual process, e.g. because the change log needs to be updated manually, and I don't think it happens so often that it's a problem. Provided we had clear instructions about incrementing the version somewhere (which we should have anyhow), I think it could be continued to be done manually to avoid introducing another generated file as such files are always a source of additional complications. ML> He simply chose to use the value defined in CMake (PR #436). Second, I'm not a CMake expert (but you know this by now), but wouldn't it be possible to extract the values from soci/version.h in CMake code instead of generating soci/version.h? E.g. by running a small program outputting the value of SOCI_VERSION? This would solve my problem and, perhaps more importantly, just makes much more sense to me: the code is primary, the build system is secondary, why should it define the version. And if you want to quickly check the current version in the SOCI sources, you're much more likely to look for it in soci/version.h than cmale/SociVersion.cmake! ML> As long as SOCI uses CMake as default builder, This is related to the relationship between the code and the build system mentioned above: even if we don't plan to change it now or in the near future, it's hard to argue that CMake will always continue to be used (and personally I strongly hope it won't), so we shouldn't put the "primary" version information in it. If it can extract it from the sources -- why not, but I'd rather duplicate it here and there than removing it from the sources completely. ML> I'm not concerned about custom user-defined build configurations. Again, I think I'm not the only one building CMake on my own and this change just seems to be creating problems for people using it like this without sufficiently good reasons. a> But I disagree having macro named SOCI_HAVE_CONFIG_H. That means that a> everyone using SOCI will have to define this macro. I meant defining it in CMake, of course, so that you wouldn't have to do anything if you use it -- but neither would you have to do anything if you don't use it. Maybe you're right and it would be better to call it just SOCI_CMAKE instead as we can be sure that soci-config.h exists if it's defined. AFAICS I should just add add_definitions(-DSOCI_CMAKE) (BTW, another reason why CMake syntax is so ridiculous: why should we have "-D" in add_definitions() argument? This is minor but it really doesn't make any sense...) directly to CMakeLists.txt, or is there some better way of doing this? Thanks, VZ
pgp_wGkNpJ9L3.pgp
Description: PGP signature
------------------------------------------------------------------------------ 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
