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.
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.
Restore the macro removed in 0d6f2f2b85 (Remove wxSuffix from MSBuild
files, it's always "u" now, 2022-10-28) as it can still be used in the
user projects importing wx properties files and it doesn't cost anything
to keep it.
Use wxOSX_USE_NSCELL_RENDERER to allow setting it to 0 to revert to the
old code.
Note that the new version is Objective C++, so the old .cpp file had to
be renamed to have .mm extension.
Closes#24053.
Co-Authored-By: Vadim Zeitlin <vadim@wxwidgets.org>
Having this line is not useful at all as it doesn't contain any
information and shouldn't be filled in the future as git-shortlog can
provide the information about people who changed the given file more
more reliably than consulting the comments in any case.
Keep the non-blank lines for historical purposes.
When the wxWidgets sources are in a path containing '++', CMake would
show errors on the command line:
[cmake] RegularExpression::compile(): Nested *?+.
[cmake] RegularExpression::compile(): Error in compile
This happens because the full path was interpreted as a regular
expression when creating the source_groups. Without wxSOURCE_DIR the
regular expressions still match and create correct source groups, so
remove it.
Closes#22738.
Closes#23943.
Just include wxWebViewChromium in the webview library if it's enabled
during the build.
There doesn't seem to be any reason to build a separate library for it,
it's not really different from the other disabled by default wxWebView
backend (Edge).
And now that we don't need to link with an extra library, there is also
no need to have a separate webview_chromium sample, so just add a
possibility to run webview sample itself using Chromium backend by
setting WX_WEBVIEW_BACKEND environment variable.
This has the advantage of returning libraries in their load order, which
is more useful than the unspecified order that was used before.
It also means that this function now has a chance of working under other
systems such as FreeBSD, which also provides dl_iterate_phdr().
