| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Changes will default Windows SDK version as well as Platform Toolset to
the default versions used in the targeted VS version. If the projects are
opened up in VS2015, it should default to Windows SDK 8.1 and v140, but if
the same projects are opened in VS2019, it will default to latest Windows SDK 10
and v142. This way the project files should adapt to used VS version, meaning
that we could still build them using VS2015 (what's currently used on CI) but also
using VS2017 and VS2019. There should not be a need to install any previous versions
of build tools, unless an older version is targeted. It is also possible to set
PlatformToolset when calling msbuild and that should adapt to corresponding default
Windows SDK version for targeted toolset version.
Commit makes many changes and adjustments, aligning all vcxproj files but changes
should not affect build output.
|
|
|
|
builds.
When running tests on CI the runtime is configured from autogen.sh script.
When running fullaot there are a couple of features not supported so they are
disabled. The problem is that the MSVC Windows builds have its own winconfig.h
template, losing all the disabled features from configures config.h.
This commit adds support to detect the disable defines from configures config.h
if one exists. Since the complexity of this step increases the work previously
done in winsetup.bat has been moved into a msbuild target that is used from
both within VS build as well as winsetup.bat (there are a couple of other builds
using that bat file, so won't remove it).
The winconfig.h template we had is quite outdated compared to what’s generated
by configure. This commit also updates the winconfig.h to closer match what generated
for corresponding mingw build but keep all the Windows specific configurations
included in current version.
|
|
platforms.
Several of the name changes fixes MSVC warnings where local variables
hides global variables using the same name.
Number of adjustments not building on platforms not defining HAVE_CLASSIC_WINAPI_SUPPORT.
Fix a couple of build projects not setting dependencies on build-init.vcxproj.
This could cause races in build order if projects depend on build initialization.
Added support to force external builds to use msbuild even if ninja is present.
|
|
(#11946)
* Add support for LLVM asserts in internal LLVM build on Windows.
* Only build LLVM using MSVC if not cross compiling.
If not cross compiling, building runtime where host/target is Windows, only
build and use LLVM as part of msvc build (only supported configuration),
disabled on gcc build.
Enforce 64-bit LLVM support when building using Visual Studio solution file.
* Disable Windows LLVM Visual Studio build on unsupported configurations.
Automatically disable Windows LLVM build in Visual Studio. This enables
the option to configure using --enable-llvm but still build all runtime
configurations from within Visual Studio. A warning will be issued into
build logs when LLVM support is disabled for a specific build configuration.
* Fix so build-init always have cygconf.h available when needed.
|
|
|
|
|
|
|
|
build. LLVM build follows similar pattern as BTLS build and will be build
as part of regular Visual Studio build Mono runtime if LLVM has been enabled
through the autogen.sh, --enable-llvm or –with-llvm argument. It is also
supports msbuild properties MONO_ENABLE_LLVM, MONO_EXTERNAL_LLVM_CONFIG,
if Visual Studio Mono runtime has been built without using autogen.sh.
When just using –enable-llvm, LLVM build will try to build internal LLVM
branch under external/llvm or if override has been set in props file
(using MONO_INTERNAL_LLVM_SOURCE_DIR), an alternative LLVM source
directory path. If –with-llvm has been used pointing to an llvm-config.exe,
no internal LLVM will be build, but the external LLVM build will be used.
Needed LLVM executables (opt.exe, llc.exe) will be installed into regular
Visual Studio Mono runtime build output directory.
The internal Mono LLVM 6.0 release will build as part of changes to this
commit, but it has not yet been fixed to work as expected during runtime.
That work will be done in different commit. The Mono LLVM 3.6 branch will
however work as expected for Windows x64 and can be setup and used using
–with-llvm argument or build as part of Visual Studio build Mono runtime
by enabling msbuild properties, MONO_ENABLE_LLVM and
MONO_INTERNAL_LLVM_SOURCE_DIR.
|
