Change Details

I have two things I'd like to raise concerning QGpgME, I hope a "nobug" ticket isn't too inappropriate for that. I searched for "qgpgme" before creating this ticket, and found nothing that seemed relevant judging from the ticket titles. - something went amiss during the conversion from CMake to autoconf: on Mac the QGpgmeConfig.cmake file still uses a .so shared library extension instead of the correct .dylib . This is an actual bug, but maybe already fixed in the upcoming version (like the similar issue and the lingering @libsuffix@ I encountered in the generated other gpgme .cmake files)? - QGpgME builds libqgpme, preserving the same name as the library that used to be built by kdepimlibs4. Most if not all generic libraries have adopted Qt's own approach of including the major version in the library name, to allow co- existence of Qt4 and Qt5 versions (e.g. libQtCore vs libQt5Core). I have verified: a simple search-and-replace of libqgpg with libqt5gpg in the qt subdirectory suffices to build a library that can co-exist with the old Qt4 version from kdepimlibs4. Dependent software that uses CMake to find its dependencies will find the libraries under that name without any issue. Is this something that might be considered upstream, e.g. for 1.8.1, possibly as a build option? I realise this may not be something that has already come up on Linux desktops but it's likely to do so in other distribution systems; it is blocking us in MacPorts at this moment, for instance.

I have two things I'd like to raise concerning QGpgME, I hope a "nobug" ticket isn't too inappropriate for that. I searched for "qgpgme" before creating this ticket, and found nothing that seemed relevant judging from the ticket titles. - something went amiss during the conversion from CMake to autoconf: on Mac the QGpgmeConfig.cmake file still uses a .so shared library extension instead of the correct .dylib . This is an actual bug, but maybe already fixed in the upcoming version (like the similar issue and the lingering @libsuffix@ I encountered in the generated other gpgme .cmake files)? - QGpgME builds libqgpme, preserving the same name as the library that used to be built by kdepimlibs4. Most if not all generic libraries have adopted Qt's own approach of including the major version in the library name, to allow co-existence of Qt4 and Qt5 versions (e.g. libQtCore vs libQt5Core). I have verified: a simple search-and-replace of libqgpg with libqt5gpg in the qt subdirectory suffices to build a library that can co-exist with the old Qt4 version from kdepimlibs4. Dependent software that uses CMake to find its dependencies will find the libraries under that name without any issue. Is this something that might be considered upstream, e.g. for 1.8.1, possibly as a build option? I realise this may not be something that has already come up on Linux desktops but it's likely to do so in other distribution systems; it is blocking us in MacPorts at this moment, for instance.

I have two things I'd like to raise concerning QGpgME, I hope a "nobug" ticket isn't too inappropriate for that. I searched for "qgpgme" before creating this ticket, and found nothing that seemed relevant judging from the ticket titles. - something went amiss during the conversion from CMake to autoconf: on Mac the QGpgmeConfig.cmake file still uses a .so shared library extension instead of the correct .dylib . This is an actual bug, but maybe already fixed in the upcoming version (like the similar issue and the lingering @libsuffix@ I encountered in in the generated other gpgme .cmake files)? - QGpgME builds libqgpme, preserving the same name as the library that used to be built by kdepimlibs4. Most if not all generic libraries have adopted Qt's own approach of including the major version in the library name, to allow co- existence of Qt4 and Qt5 versions (e.g. libQtCore vs libQt5Core). I have verified: a simple search-and-replace of libqgpg with libqt5gpg in the qt qt subdirectory suffices to build a library that can co-exist with the old Qt4 version from kdepimlibs4. Dependent software that uses CMake to find its dependencies will find the libraries under that name without any issue. Is this something that might be considered upstream, e.g. for 1.8.1, possibly as a build option? I realise this may not be something that has already come up on Linux desktops but it's likely to do so in other distribution systems; it is blocking us in MacPorts at this moment, for instance.