* m4/qt6.m4: Check the build configuration of Qt 6 for
no_direct_extern_access.
--
If building with -mno-direct-extern-access has been neither enabled nor
disabled explicitly, then check whether Qt 6 was built with this flag.
The check is skipped, if we build for Windows.
GnuPG-bug-id: 6696
* configure.ac: Check if C++ compiler supports
-mno-direct-extern-access. Add option to enable building with
-mno-direct-extern-access.
* m4/ax_check_compile_flag.m4: New.
* m4/qt6.m4: Add -mno-direct-extern-access to GPGME_QT6_CFLAGS if
supported and requested.
--
This adds the possibility to build the Qt 6 bindings with the
-mno-direct-extern-access flag. This is required if Qt 6 was built with
this flag. This is a workaround for the lack of Qt 6's pkgconfig files
providing this flag if needed.
GnuPG-bug-id: 6696
* m4/qt6.m4: Remove attempt to build a Qt program with -fPIC.
--
libtool already takes care of adding -fPIC. Moreover, building without
-fPIC succeeded even if Qt was built with -fPIC, i.e. the check didn't
work as intended.
GnuPG-bug-id: 6696
* configure.ac: Unset PYTHON_LIBS. Support python 3.10.
* m4/python.m4: Find correct version string for python >= 3.10.
--
See-also: https://dev.gnupg.org/D546
Also test for 3.11 and 3.12 (wk).
* m4/qt5.m4, m4/qt6.m4: Perform build test only if moc was found.
--
If moc wasn't found but the build test (which doesn't require moc)
succeeded, then success was reported.
* m4/qt6.m4: Do not add -fpic to GPGME_QT6_CFLAGS. Add -fpic to CPPFLAGS
used for build test of simple Qt 6 application.
--
The pkgconfig files of Qt6Core do not contain the qt_config variable,
so that we cannot easily check whether Qt6 was compiled with pic. For
simplicity we always compile the test application with -fpic to avoid
a build failure if Qt6 was actually compiled with pic.
For the actual build of QGpgME libtool automatically uses -fPIC, so that
we don't have to add it to the GPGME_QT6_CFLAGS.
* configure.ac: Look for Qt 5 and/or Qt 6. Require C++17 if Qt 6 binding
is built. Build cmake files QGpgmeConfig* for Qt 5 and QGpgmeQt6Config*
for Qt 6.
(available_languages): Add "qt5" and "qt6".
(WANT_QT5, WANT_QT6): New conditionals.
* lang/qt/src/Makefile.am: Keep building libqgpgme for Qt 5. Build
libqgpgmeqt6 for Qt 6.
* lang/qt/tests/Makefile.am: Build tests for Qt 5 or Qt 6.
* lang/qt/src/QGpgmeQt6Config-w32.cmake.in.in,
lang/qt/src/QGpgmeQt6Config.cmake.in.in,
lang/qt/src/QGpgmeQt6ConfigVersion.cmake.in, m4/qt6.m4: New.
--
This makes it possible to build QGpgME optionally for Qt 6.4.0 or later.
By default or if the language "qt" is enabled, then QGpgME is built
either for Qt 5 (if found) or Qt 6. A build for Qt 5 or Qt 6 can be
requested by explicitly enabling the language "qt5" or "qt6". Building
QGpgME for Qt 5 and Qt 6 simultaneously is not supported.
m4/qt.m4: Rename to
m4/qt5.m4: this.
(FIND_QT): Rename to FIND_QT5.
(GPGME_QT): Change variable prefix to GPGME_QT5.
(GPGME_QTTEST: Change variable prefix to GPGME_QT5TEST.
configure.ac, lang/qt/src/Makefile.am, lang/qt/tests/Makefile.am:
Adjust accordingly.
--
In preparation to adding support for building qgpgme for Qt6, add the
version number to a few variables to avoid confusion.
* m4/ax_cxx_compile_stdcxx.m4: Replace with current version from the
autoconf archive.
--
This fixes the problem that the switch -std=c++11 was omitted if the
compiler supported C++11 features by default. This made gcc happily
compile C++14 code. Now C++11 is enforced by gcc.
GnuPG-bug-id: 6141
* configure.ac: Add -fvisibility=hidden to GPGME_CPP_CFLAGS if gcc
supports the flag.
* lang/cpp/src/Makefile.am (AM_CPPFLAGS): Add GPGME_CPP_CFLAGS.
* m4/ax_gcc_func_attribute.m4: New.
--
With this change all defined symbols are hidden by default, so that they
are not exported anymore. All symbols that are part of the ABI and that
shall still be exported are already marked as having default visibility.
The m4 macro was taken from the website mentioned in the License header
of the file.
GnuPG-bug-id: 5906
* m4/libtool.m4: Not setting 10.0 to MACOSX_DEPLOYMENT_TARGET when not
defined. Only specify -flat_namespace to linker for specific
(older) versions and hosts.
--
Original patch was by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
in
https://lists.gnu.org/archive/html/libtool-patches/
2020-06/msg00001.html
Reported-by: Aleix Conchillo Flaque
GnuPG-bug-id: 5610
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* configure.ac: Use AC_USE_SYSTEM_EXTENSIONS instead of AC_GNU_SOURCE.
Use AS_HELP_STRING instead of AC_HELP_STRING.
* m4/libtool.m4: Update from libgpg-error.
* m4/gpg-error.m4: Update from libgpg-error.
* m4/libassuan.m4: Update from libassuan.
Signed-off-by: NIIBE Yutaka <gniibe@fsij.org>
* m4/python.m4: Scan for python 3.8 as well.
--
It's not clear to me why python3.8 should be commented out of the
python path search. This change simplifies and normalizes the search
for modern versions of python 3.
Signed-Off-By: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
* m4/python.m4 (AM_PATH_PYTHON): Add a 4th arg.
* configure.ac (available_languages): Remove separate python2 and
python3 and keep just python. Simplify test for pythons. Use an
explicit list of python versions to test.
--
This seems to be a starightforward chnage to support more than two
python versions. I am not sure why we had that complicated thing
before. On my box I get builds and run tests for 2.7, 3.4 and 3.5.
If 3.6, 3.7 or 3.8 are installed they should also work.
GnuPG-bug-id: 3354
Signed-off-by: Werner Koch <wk@gnupg.org>
* Changed the order of python versions the configure/make process
checks for, placing Python 3.7 ahead of 3.6.
* Updated the HOWTO documentation to reflect this change.
Tested-by: Ben McGinnes <ben@adversary.org>
Signed-off-by: Ben McGinnes <ben@adversary.org>
* Bindings confirmed to work with the newly released 3.7.0.
* Updated M4 file to reflect this change and correct the Python binary
search order (3.7 is not yet given priority, but will still be found
first via the more generic python3 executable).
* Updated setup.py.in, bindings documentation and README to reflect this.
* m4/python.m4 (_AM_PYTHON_INTERPRETER_LIST): Prefer the generic
'pythonX' over 'pythonX.Y'. This way we select the users preferred
version for both flavors. Prefer 'python' over 'python3' but not over
'python2' so that the algorithm still finds a 'python2' even if
'python' is a Python3.
Fixes-commit: 5189c08af9
Signed-off-by: Justus Winter <justus@g10code.com>
* m4/ax_python_devel.m4: Do not emit 'HAVE_PYTHON'.
* m4/python.m4 (_AM_PYTHON_INTERPRETER_LIST): Add newer Python
versions, drop older ones. Also, sort the list with older versions at
the front, newer and generic versions towards the end. This makes the
algorithm pick the lowest version that meets the version requirement.
Signed-off-by: Justus Winter <justus@g10code.com>
* m4/qt.m4: Use grep -E when using the alternation character.
--
POSIX specifies '|' is only supposed to work as an alternation special
character when grep is used in extended mode. The code worked fine
with GNU grep because it accepts extended regular expressions by
default, but other POSIX-compliant implementations might fail and take
it literally.
Signed-off-by: Raphael Kubo da Costa <rakuco@FreeBSD.org>
* configure.ac: Try to compile a Python module for each version.
* m4/m4_ax_swig_python.m4: Drop unused file.
Signed-off-by: Justus Winter <justus@g10code.com>
* m4/qt.m4 (FIND_QT): Check if a qt application can be compiled and
linked.
--
In case gpgme is cross compiled pkg-config may pick up qt
for the build system and not for the host system. To avoid that
we check that we can compile a qt program for host.
Previously, missing Python development packages made configure fail
instead of merely disabling the bindings.
* configure.ac: Check for 'PYTHON_VERSION'.
* m4/ax_python_devel.m4: Make test non-fatal.
Signed-off-by: Justus Winter <justus@g10code.com>
* m4/ax_cxx_compile_stdxx.m4 (AX_CXX_COMPILE_STDCXX): Set CXXCPP if
neccessary.
--
This fixes the build with scan-build where CXXCPP is already set but
does not include stdc++11. While this deviates from the
autotools-archive version of the script it does not make sense
to me first to check if stdc++11 needs to be set and then not
set it.
* configure.ac: Make Python bindings configurable, add new Makefile.
* lang/python/Makefile.am: New file.
* lang/python/setup.py: Integrate into the build system.
* m4/ax_pkg_swig.m4: New file from the autoconf archive.
* m4/m4_ax_swig_python.m4: Likewise.
Signed-off-by: Justus Winter <justus@gnupg.org>
* configure.ac: Call ax_cxx_compile_stdcxx
* m4/ax_cxx_compile_stdcxx.m4
--
Depending on c++11 is intended to make the port away from
Boost easier.
The m4 macro was taken from the website mentioned in the License
header of the file.
* configure.ac: Configure test Makefile.
* m4/qt.m4: Look up Qt5Test flags.
* lang/qt/tests/t-keylist.cpp: New. Simple keylist check.
* lang/qt/tests/Makefile.am: New. General test framework.
--
This test mostly checks that it basically compiles / works and
adds a test framework.
* configure.ac: Add version defines. Check for qt if neccessary.
* lang/README: Mention qt
* lang/cpp/src/GpgmeppConfig.cmake.in.in: Remove comment. Find qgpgme.
* lang/qt/src/Makefile.am: New. Build qgpgme.
* lang/qt/README,
lang/qt/src/Makefile.am,
lang/qt/src/QGpgmeConfig.cmake.in.in,
lang/qt/src/QGpgmeConfigVersion.cmake.in,
lang/qt/src/dataprovider.cpp,
lang/qt/src/dataprovider.h,
lang/qt/src/qgpgme_export.h,
m4/qt.m4: New.
* lang/cpp/src/GpgmeppConfig.cmake.in.in,
lang/cpp/src/Makefile.am: Fix generated config file.
--
For now this is just the dataprovider which was part of the
KF5 Gpgmepp QGpgme variant. This is very thin but a useful
class which is used downstream.
* build-aux/ltmain.sh (sed_uncomment_deffile): New.
(orig_export_symbols): Uncomment def file before testing for EXPORTS.
* m4/libtool.m4: Do the same for the generated code.
--
The old code was not correct in that it only looked at the first line
and puts an EXPORTS keyword in front if missing. Binutils 2.22
accepted a duplicated EXPORTS keyword but at least 2.23.2 is more
stringent and bails out without this fix.
There is no need to send this upstream. Upstream's git master has a
lot of changes including a similar fix for this problems. There are
no signs that a libtool 2.4.3 will be released to fix this problem and
thus we need to stick to our copy of 2.4.2 along with this patch.
Signed-off-by: Werner Koch <wk@gnupg.org>
