* m4/python.m4: Add python3.12 and 3.11 as valid interpreters, remove
EOL 3.4, 3.5, 3.7 (keep 3.6 because some distributions still ship and
maintain it).
* lang/python/Makefile.am (clean-local): Remove dist and gpg.egg-info
created by Python 3.9+ on make install.
* lang/python/setup.py.in: switch from distutils to setuptools where
possible, remove obsolete and deprecated -py3 option of swig, add
classifiers up to 3.12, remove 3.4, 3.5, 3.7.
* lang/python/doc/src/gpgme-python-howto.org: replace distutils with
setuptools
* lang/python/examples/howto/advanced/cython/setup.py: replace distutils
with setuptools
--
This fixes building the Python bindings for Python 3.12 where distutils
has been removed.
Based on D545
* m4/ax_python_devel.m4: Do not emit 'HAVE_PYTHON'.
--
This reapplies the changes made with 5189c08 that are still needed for
detecting multiple Python versions.
* configure.ac: Call AX_PYTHON_DEVEL with new "optional" argument.
* m4/ax_python_devel.m4: Replace with current version from the autoconf
archive.
--
The new "optional" argument allows us to leave out one of our custom
changes.
* configure.ac: Add option to enable building the Qt 6 binding with
-fPIC. Fix typo and mention default for --enable-no-direct-extern-access
option.
* m4/qt6.m4: Add -fPIC to GPGME_QT6_CFLAGS if requested or if Qt 6 was
built with reduce_relocations.
--
GnuPG-bug-id: 6781
* 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.
