RJVB (René Bertin)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Saturday

  • Clear sailing ahead.

User Details

User Since
Mar 27 2017, 4:48 PM (89 w, 2 d)
Availability
Available

Recent Activity

Jan 11 2017

RJVB added a comment to T2733: alternate header directory (--includedir) isn't set in GpgmeppConfig.cmake.

It seems like indeed it should have been resolved. I have also resolved the issue
by moving the old headers from KDEPIMLibs 4 to a private location, and KF5
projects have apparently been updated to work with gpgme++ installed in
$prefix/include/gpgme++ .

Jan 11 2017, 4:39 PM · gpgme, Bug Report
RJVB reopened T2733: alternate header directory (--includedir) isn't set in GpgmeppConfig.cmake as "Open".
Jan 11 2017, 4:39 PM · gpgme, Bug Report

Jan 2 2017

RJVB added a comment to T2884: Qgpgme thoughts and issues.

Hi,

The patch works. There's 1 more issue that's been standing for a bit longer already,
and that you might want to tackle at the same time: there's no argp.h header on Mac.

On Linux it is only a problem with the headers (e.g. the -dev) Package as the

That's actually an orthogonal issue, and one that's probably easier to rectify as any
changes only become apparent when dependent software is being built.

libraries have different soversions

This is also the case on Mac, but the link library doesn't have a soversion. It's
called libqgpgme.so or libqgpgme.dylib .
There is of course the option to rename just that symlink. A bit of a hack, but one
that's relevant only during the link step, when dependent software is being rebuilt.

How does MacPorts handle this in general? IMO this is not a (q)gpgme(++)
specific problem as you will have this problem with each ABI break.

MacPorts does many things like they're done on more traditional *n*x desktops, i.e.
install libraries in a central, shared location (--prefix=/opt/local by default).
There is nothing specific it does to handle ABI breaks; they can hold up an upgrade,
or a patch is applied at some level, or a conflict is registered. Sadly there is no
central way to create -dev packages, which doesn't help here.

E.g. when we
break the ABI in QGpgME libqt5qgpgme.dylib may be incompatible and we would need
a new name.

That I don't see. The problem here isn't so much the ABI break compared to the
version shipped by kdepimlibs4, but the fact that an incompatible Qt version is used.
So no, a SOVERSION=8 upgrade doesn't impose a library name change. Cf. Poppler and
its Qt backends; they're called libpoppler-qt4 and libpoppler-qt5 .
An alternative would be to do like QCA: install the library wherever Qt's own
libraries are installed. That automatically resolves the conflict with the old
version included with kdepimlibs4, and might be less disruptive for existing
distribution packages.

It's not only the build system but the code using QGpgME / GpgME++ will be more
complex as they would need to have feature checks for both the QGpgME version

What I had in mind was a build system that refuses to do a mismatching build of QpgME
X.Y.Z against GpgME++ that's not X.Y.Z . If you don't do runtime checks there's no
guarantee anyway beyond what the dynamic linker can give, I think. Distributions can
build QpgME and only bundle the QpgME bits, and then install that against any GpgME
install. I've done that for a bit with QpgME 1.7.x against QpgME++ 1.8.0, and didn't
run into any issues.
You could probably even argue that people would be less likely to try this kind of
things if the build system gave off a big hint that they really shouldn't be doing
that. It's not like it's particularly difficult to install only QpgME, after all.

Jan 2 2017, 5:21 PM · gpgme, qt, Feature Request

Dec 21 2016

RJVB added a comment to T2884: Qgpgme thoughts and issues.

It will probably a bit more complex to maintain the buildsystem because you'd
want to exclude builds against mismatching qgpgme versions, but when done that
should be all, no?

It's just a bit a pity that you have to build all of the cpp bindings again if
you just want to build the Qt bindings.

Dec 21 2016, 6:50 PM · gpgme, qt, Feature Request
RJVB added a comment to T2884: Qgpgme thoughts and issues.

Something else that would be nice is a possibility to build (and install) just
QGpgME, against an already installed gpgme. Would that be hard to achieve?

Dec 21 2016, 2:18 PM · gpgme, qt, Feature Request
RJVB added a project to T2885: missing prototypes in qpgme (OS X): Bug Report.
Dec 21 2016, 12:56 PM · Unreleased, Bug Report, MacOS
RJVB added a comment to T2885: missing prototypes in qpgme (OS X).

D404: 932_qgpgme.diff

Dec 21 2016, 12:56 PM · Unreleased, Bug Report, MacOS
RJVB set Version to 1.8.0 on T2885: missing prototypes in qpgme (OS X).
Dec 21 2016, 12:56 PM · Unreleased, Bug Report, MacOS
RJVB set Version to 1.8.0 on T2884: Qgpgme thoughts and issues.
Dec 21 2016, 11:23 AM · gpgme, qt, Feature Request

Oct 1 2016

RJVB added projects to T2733: alternate header directory (--includedir) isn't set in GpgmeppConfig.cmake: Bug Report, gpgme.
Oct 1 2016, 2:12 PM · gpgme, Bug Report