It shouldn't, and now doesn't, use these libraries directly and
shouldn't depend on them to avoid introducing unnecessary requirements
for the applications which use it without XRC.
Previously this was used only for linking the samples, which ensured
that they found the libraries directly referenced by them, but this
wasn't enough to find the libraries referenced indirectly, via another
library (e.g. wxxml used by wxxrc internally but not necessarily
referenced by the sample using XRC) because DT_RUNPATH is not used in
this case, as documented in Linux ld.so(8).
Ensure that such libraries are found nevertheless by setting runpath
for all the libraries too.
Note that it would probably be more logical to just get rid of
SAMPLES_RPATH_FLAG and use DYLIB_RPATH_FLAG everywhere, but this would
result in a ton of changes, so keep the old variable for now and just
set it to the same value to avoid this and keep the possibility to
change it to a different value if necessary later.
wxBUILD_CXX_STANDARD is initialized with CMAKE_CXX_STANDARD. But if the user changes
the value of CMAKE_CXX_STANDARD, it would keep using the old wxBUILD_CXX_STANDARD value.
And any other warnings that libcef_dll_wrapper might show, like missing doxygen package.
For debug purposes, add an option CEF_SHOW_RESULTS to keep showing it.
webview_chromium.cpp requires using C++17 as it includes CEF headers
that require it (e.g. they use std::in_place) and we need to use the
same options all files in this project as they share the same PCH, so
just use C++17 for all of them -- it should do no harm.
The previous error didn't make sense if CMAKE_CXX_STANDARD wasn't set,
so use a slightly different message in this case.
Also improve the comment explaining why we need C++17 in the first
place.
Co-Authored-By: Maarten Bent <MaartenBent@users.noreply.github.com>
Previously CMake would give an error if CMAKE_CXX_STANDARD wasn't
explicitly set to C++17 or greater when using CEF, but this is not
really needed if the compiler supports C++17 without any non-default
options, so check for this too.
wxMSW could already be compiled for ARM with MSVC, but due to not
defining any ARCH_SUFFIX for ARM, makefile.vc used to place objectsi
and libraries to the same folder as x86 objects and libraries.
A completely different question is what kind of Windows runs on 32-bit
ARM, and whether one can run regular desktop apps on it.
This commit mimics what f69dbaa1 did for ARM64, and adapts it for ARM.
Closes#24222.
If it isn't, as is the case for MSVS for example, we don't need to set
wxHAVE_CEF_DEBUG anyhow, as it's set automatically if _DEBUG is defined
during the build.
Co-Authored-By: Maarten Bent <MaartenBent@users.noreply.github.com>
Use the compiler default C++ dialect if it is C++11 or higher and only
explicitly request C++11 if the compiler can't compile a small test
using C++11 features by default.
This prevents from unnecessarily adding -std=c++11 to the compiler flags
under Unix, even with compilers using e.g. C++17 by default.
This reverts commit 3d51977acf because
it's incompatible with the library names created by CMake when building
CEF directly, and not via wx CMake files.
Although building CEF itself requires C++17, C++14 is sufficient for
building libcef_dll_wrapper, so allow using it.
Also move the error message a bit more informative.
If it is enabled (e.g. globally because the application using wxWidgets
as a submodule enables it), it would result in a harmless warning about
not calling the base class ctor in base/cef_callback_internal.cpp.
Check for 'libcef_dll' instead of 'cef_paths.gypi', because the minimal distribution doesn't contain the last one.
Mark all CEF variables as advanced, so they don't show up in the default CMake GUI.
