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.
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.
Add wxRuntimeLibs property which is set to "dynamic" by default, but can
also be set to "static" (e.g. with "msbuild /p:wxRuntimeLibs=static") to
build the libraries using static CRT libraries.
Closes#22693.
This property expands to either (just) "d" (even in Unicode builds) or
nothing depending on whether we're building in debug or release and can
be used to construct the configuration-independent names for the third
party libraries, most of which use just this suffix and not wxSuffix,
which expands to "ud" in (Unicode) debug build.
This allows to use exactly the same link dependencies for both debug and
release configurations, as demonstrated by the updated minimal MSVS
project file, which is convenient when creating new projects not using
wxwidgets.props, as it allows to enter the dependencies just once and
use them for all build configurations instead of having to enter them
separately for the debug and the release ones.
No real changes, just use the same _PropertySheetDisplayName element as
the standard style sheets use to show a slightly more user-friendly
label in the Property Sheet manager window in MSVS.
Use /Zc:throwingNew option for the compilers supporting it instead of
defaulting to compatible behaviour, which assumes that operator new can
return NULL on allocation failure, that we don't need, at least in the
release builds.
This is also slightly more efficient as it allows the compiler to avoid
generating null checks after calling new.
Closes#19069.
Done by running misc/scripts/inc_release, manually updating version.bkl,
rebaking and rerunning autoconf.
Also a header for the next version to the change log.
This is a preliminary ARM64 platform support for wxWidgets at "it
compiles" stage. This will allow building and testing wxWidgets based
apps for oncoming Windows 10 ARM64.
Requirements:
- Visual Studio 2017 Update 4 or later with Visual C++ compilers and
libraries for ARM64 component installed
Building:
1. Open command prompt.
2. Change directory to build\msw subfolder.
3. Run "C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\VC\Auxiliary\Build\vcvarsamd64_arm64.bat" once.
4. Use `nmake TARGET_CPU=ARM64 ...` to build required flavor of wxWidget
libraries.
Notes:
1. Building of *.sln/*.vcxproj files does not support ARM64 yet. This
requires to hardcode Windows SDK to 10.0.15063.0 or later in
*.vcxproj files, which would render them non-compilable in older
Visual Studio versions. Microsoft is aware of this issue and is
planning a fix in the next version of Visual Studio.
2. wxmsw31ud_gl.dll does not build yet. Awaiting Microsoft to deliver
missing opengl32.lib for ARM64. Please, specify USE_OPENGL=0.
Closes https://github.com/wxWidgets/wxWidgets/pull/923
Disable thread-safe initialization for static local variables in Visual Studio
2015 when XP toolset is used as this results in crashes when using DLLs under
XP, see #13116.
Closes#17403.
Update misc/scripts/inc_release script: remove non-existent any more files and
update the version in the MSVS 200x project files not generated by bakefile
any more and MSVS 201x project files which were not previously taken into
account.
Run it and rebake.
This makes them compatible with the makefiles and MSVS 200x projects.
Notice that wxVersionString will need to be set to "32", not "320", when 3.2.0
release is done, as the micro version component is only used in the DLL names
for the development releases but not stable ones.
This will be useful for allowing other projects, not necessarily located at
the same level of the file hierarchy as the projects for building the library,
to refer to the location of the libraries more easily.
Get rid of version-specific MSVS project files, we can reuse the same projects
for all MSBuild-based versions, i.e. 2010, 2011 and 2013.
git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@77008 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775
