Installing this package directly fails because of a conflict between one
of its dependencies and the already installed libc++-dev which depends
on another, incompatible, version of the same library.
Work around this by installing libunwind-dev directly, which is enough
to make apt uninstall libc++-dev and libunwind-14-dev that it depends on
instead of just stopping with an error.
It's not really clear how are we supposed to use clang with libc++ in
this environment, but this at least allows to build with gcc.
CONFIG mode uses the <packageName>_DIR variable.
CMake has an error when generating the solution because the
lib/vc_x64_dll/mswud directory does not exist; it is not built and installed.
So only add the used configuration.
They're not handled by the current 7z version under MSW if the user
doesn't have administrative rights and, instead of dealing with this,
it's simpler to just never include any symlinks in the archives as we
don't really need them anyhow.
So add a check ensuring that no symlinks are included in the
distribution archives to avoid more problems such as the one fixed in
the parent commit in the future.
The default httpbin listening port 5000 is used by Monterrey (macOS 12)
Control Center for its own needs, so use another port to avoid conflicts
with it and the resulting failures when running wxWebRequest unit tests
under this macOS version.
Fix the last known working Flask version, the latest one results in the
errors like the following
Traceback (most recent call last):
File "/usr/lib/python3.8/runpy.py", line 185, in _run_module_as_main
mod_name, mod_spec, code = _get_module_details(mod_name, _Error)
File "/usr/lib/python3.8/runpy.py", line 111, in _get_module_details
__import__(pkg_name)
File "/home/runner/.local/lib/python3.8/site-packages/httpbin/__init__.py", line 3, in <module>
from .core import *
File "/home/runner/.local/lib/python3.8/site-packages/httpbin/core.py", line 22, in <module>
from werkzeug.wrappers import BaseResponse
ImportError: cannot import name 'BaseResponse' from 'werkzeug.wrappers' (/home/runner/.local/lib/python3.8/site-packages/werkzeug/wrappers/__init__.py)
It seems like this function sometimes doesn't return non-zero exit code
even though it fails to fetch some packages (e.g. due to a network
error), so log its status code to check if this is really the case.
This is needed since GitHub CI images update to windows-2022 base image,
which notably changes Python version from 3.7 to 3.9 and requires
building wheels for some of the packages not available on PyPI for this
version.
Closes#22091.
libwebkitgtk-3.0-dev is long deprecated and isn't used anyway.
gstreamer-0.10* no longer exists even on Ubuntu 18.04.
gstreamermm* is not used by wxWidgets.
Closes#22069.
This is not necessary any longer since the changes of 1b76ff4887
(Disable wxWebRequest tests on CI platforms without Python 3,
2021-05-16) as we require Python 3 for httpbin anyhow.
This currently means macOS 10.11 only, which is only used on Travis CI
and Python 2 installation there is broken anyhow, so this doesn't make
anything worse than it already is.
Python package hosting seems to randomly decide which version of the
package to return to pip running under Trusty: in addition to werkzeug
(see last commit), the version of flask has spontaneously changed from
1.0 to 1.2 in the latest build too.
Just hardcode the versions of all dependencies in the last successful
build and hope they keep working for longer than a day.
Crazily, pip installs seem to be non-deterministic as installing httpbin
in https://travis-ci.org/github/wxWidgets/wxWidgets/jobs/765946720
pulled in werkzeug 0.16.1 which works with Python 3.4, but doing it
again tries to use werkzeug 1.x which isn't.
Fix the version explicitly to work around this.
Trying to use Python 2 under Trusty is hopeless, as pythonhosted.org has
already started dropping support for non-SNI clients and will drop it
completely soon, see https://status.python.org/incidents/hzmjhqsdjqgb
and https://github.com/pypa/pypi-support/issues/978, and SNI is not
available in the system Python 2 version (2.7.6, which is less than
2.7.9 in which it was added).
Note that we still can't use Python 3 everywhere as long as we have
macOS 11 builds as it's not available there.
Amazingly, updating a package has no problems with installing a newer
version incompatible with the current Python version, such as installing
pip 21 when using Python 3.5.
Somehow installing decorator==4.4.2 worked a few times, but then stopped
and now fails with
Could not find a version that satisfies the requirement
decorator==4.4.2 (from versions: )
No matching distribution found for decorator==4.4.2
Try using explicit URL.
