Remove the platform-specific wxWebRequest headers from the files lists
and from MSVS 200x project files.
This should have been done in e5bd5a926c (Move backend-specific
wxWebRequest headers to private subdirs, 2020-12-26) manually, as
update-setup-h script doesn't remove the old files from the variable
definitions.
It notably fixes CMake build under MSW and Mac, which failed due to not
finding the referenced files.
Fix CMake build with 3.10, which gave the following errors
CMake Error at build/cmake/init.cmake:321 (check_c_source_compiles):
Unknown CMake command "check_c_source_compiles".
Call Stack (most recent call first):
build/cmake/main.cmake:16 (include)
CMakeLists.txt:69 (include)
previously. Apparently the required CheckCSourceCompiles module was
already included from somewhere else with later CMake versions, but not
with this one, so do include it explicitly.
Remove automatic definition of wxUSE_WEBREQUEST depending on whether
wxUSE_WEBREQUEST_XXX are defined and follow the same approach as with
wxUSE_GRAPHICS_XXX, i.e. define wxUSE_WEBREQUEST_XXX as wxUSE_WEBREQUEST
by default instead.
Move wxUSE_WEBREQUEST_WINHTTP to wxMSW-specific file, it doesn't need to
be in common one (unfortunately this can't be done for the Mac-specific
wxUSE_WEBREQUEST_URLSESSION yet, because macOS-specific settings are not
injected into setup.h.in currently).
Also fix test for winhttp.h availability: it seems to be present in all
MinGW64 distributions, but not in MinGW32, so test for this and not for
gcc version.
Finally remove the now unnecessary test for macOS 10.9, as we only
support 10.10+ anyhow by now.
Fix wrong library name in wx_add_sample() for webrequest.
Also prefer to disable wxWebRequest if no backends for it are available,
for consistency with the other libraries.
This reverts commit 7ec39330d2 because
enabling verbose ASAN output results in too much output for Travis to
handle (and, to be fair, for it to be useful).
This is useless, all still supported compilers except ancient MSVS
versions (for which configure is not used anyhow) support variadic
macros, so don't waste time testing for them.
Note that the checks for HAVE_VARIADIC_MACROS in the sources are still
left because it is still possible to explicitly disable variadic macros
support using --disable-vararg_macros for strict C++98 compatibility.
All still supported versions of MinGW/Cygwin provide w32api.h file, so
there is no need to test for it.
This allows to simplify the code, but also remove the definition of
HAVE_W32API_H from bake- and makefiles and this, in turn, allows to get
rid of extra flags in MinGW format entirely, as we don't support gcc
2.95 for which they were originally needed neither.
Don't rely on just a single GTK version being installed on the system,
as we do now, but select the version we want explicitly, just to avoid
bad surprises in the future (even if it doesn't change anything for
now).
As it is stated in matrix.cpp wxTransformMatrix was intended to be used
in wxDC to replace the basic system of scaling/translation but actually
it was never used.
Because applying affine transformations can be done with wxAffineMatrix2D
and wxDC::SetTransformMatrix() we can get rid of this dead code.
Closes#13114.
wxWidgets already has a mechanism for locating plugins under
$libdir/wx/*, there's no reason to duplicate it with another
compile-time symbol.
As a consequence, this makes the library relocatable via WXPREFIX again.
Fix the location where the web-extension plugin is installed to be
consistent with the primary bakefile-based build system: i.e. to use
lib/wx/x.y.z for devel versions and lib/wx/x.y for stable.
Add the source files present in the bkl but not CMakeLists.txt to the
latter one too.
Also link with AUI library now that a test file using it is included.
Closes https://github.com/wxWidgets/wxWidgets/pull/2064
And use it to get HiDPI support wherever we use GtkImage. This extends and
consolidates support for custom drawing of images which has already been added
somewhat redundantly in several places.
This reverts commit 8c9ba23eae, reversing
changes made to 5192feb38e.
Upcoming commits will try to work around the issues with art IDs related
to wxNO_IMPLICIT_WXSTRING_ENCODING in a different way.
Make the wxART_* constants const wxStrings to improve compatibility with
pre-3.1.4 code and, in particular, allow taking the address of these
constants.
See https://github.com/wxWidgets/wxWidgets/pull/1996
Memory leaks in the test programs run by configure when using GTK 2
result in configuration failures when using -fsanitize=address in
{CXX,LD}FLAGS, so fix these leaks to allow configuring using
"CXXFLAGS=-fsanitize=address LDFLAGS=-fsanitize=address" together with
--with-gtk=2 (this already worked correctly with the default GTK 3).
Closes https://github.com/wxWidgets/wxWidgets/pull/2001
Add a build option (--disable-pic, wxBUILD_PIC=OFF) to disable it.
Note that it is always enabled for shared libraries and static third party libraries.
The pre-3.1.4 definitions of the constants were just string literals,
while the type were wxString typedefs. To avoid implicit conversion
these were converted to actual wxStrings.
While the interface now matched the implementation, this has several
drawbacks:
- every use of the "constant" now is a string construction at runtime
- the constant now is an rvalue, i.e. it is impossible to take its
address.
The latter breaks its use from wxPython.
The IDs are moved to a separate file which can be included multiple
times, once from the header to have the declarations in place, and once
to instantiate the wxStrings. Using a common file avoids the declaration
and definition going out of sync.
Requires updates of expat and tiff submodules.
Most libraries have their own CMakeLists, add a comment with a suggestion to
use this for implementing build-in support.
