Review Request 129265: Port from KF5Gpgme to GpgME

[René J.V. Bertin]

> On Oct. 29, 2016, 9:18 a.m., Thomas Baumgart wrote:
> > Does this mean, KMyMoney will not compile encryption support on systems with KF5 versions prior 16.12? If so, please make your change backward compatible (if the new stuff is not found, use the old)
> 
> Andreas Sturmlechner wrote:
>     No, it means it will be independent from KDE Applications releases (there is no KF 16.08/16.12). GpgME 1.7.1 with gpgmepp bindings installs side by side with gpgmepp-16.08.3 thanks to the latter using the kf5 prefix, but it collides with the much older gpgmepp-4 from kdepimlibs-4.
> 
> René J.V. Bertin wrote:
>     You are aware that you (as in "all ye all") have made versioning a mess, one that in addition is being agitated way too frequently, right? :P
>     
>     Anyway, it's not difficult at all to avoid the install clash with the kdepimlibs4 headers. Configure and install kdelibs4 with something like `-DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4` and almost all rebuilt KDE4 software will install their headers into that KDE4 directory too.
>     It's probably a little bit trickier to avoid inclusion confusion in the compiler, though. For that to be avoided reliably GpgME would have to install all its headers into something like `${prefix}/include/gpgme` and add that path with the appropriate compiler flag.
>     
>     This may sound futile and in the long run it ought to be, but anyone following activity on the kdepim-users ML should hardly be able to disagree that there still is a very reasonable desire to keep KDEPIM4 buildable for users who require a reliable email client.
> 
> Andreas Sturmlechner wrote:
>     Heh, I just happen to submit the odd patch and claim no responsibility otherwise. ;) I don't think it's a mess though, just takes time to arrive at folks that are not that involved with KDE. That's why I like to keep things clear and precise. However, I don't think it is unreasonable for kmymoney/frameworks to depend on a very recent version of gpgme instead of an applications bundle version that is going to be unmaintained in a few weeks' time.

Re that last bit: that's not what I was getting at, of course KMM shouldn't depend on unmaintained code. Re-reading my prose I realise that it isn't very clear; what I meant was just that it'd be nice (and useful for some) if development on and use of new software doesn't make it impossible to build and run older software in the same prefix (i.e. without jumping through all kinds of hoops; kdepim4 in this case).


- René J.V.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129265/#review100378
-----------------------------------------------------------


On Oct. 26, 2016, 9:57 p.m., Andreas Sturmlechner wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129265/
> -----------------------------------------------------------
> 
> (Updated Oct. 26, 2016, 9:57 p.m.)
> 
> 
> Review request for KMymoney and René J.V. Bertin.
> 
> 
> Repository: kmymoney
> 
> 
> Description
> -------
> 
> Gpgmepp is part of GpgME since 1.7.0.
> 
> REVIEW: 129265
> 
> ---
> 
> See also for reference: https://mail.kde.org/pipermail/release-team/2016-September/009732.html
> 
> 
> Diffs
> -----
> 
>   CMakeLists.txt c535faba80db64b0a30fc5fdfb09a7a2590ab8a4 
>   config-kmymoney.h.cmake f024db61af25e291cde2eef392fe161485c82e5d 
>   kmymoney/main.cpp 694ffa28ae67ad0051b893fbdcf9b7b3624f0525 
>   libkgpgfile/CMakeLists.txt 4e366ceab3c12728276feaaec78319315fb9ea6d 
>   libkgpgfile/kgpgfile.cpp 88aac42de83d28be45ad8d1516bd94eb240ed811 
> 
> Diff: https://git.reviewboard.kde.org/r/129265/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andreas Sturmlechner
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kmymoney-devel/attachments/20161030/31512826/attachment-0001.html>