| 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.
|
|
On Windows default thread stack size has been 1MB for a long time
(both 32/64-bit). When starting to use interpreter some of the tests
include deep recursions that will hit stackoverflow on Windows
(ackermann.exe as one example). This commit adjust the default reserved
stack size to 8MB for debug builds and 1.5MB (same as coreclr), for main
thread only. All other threads will still default to 1MB stack size
(both debug/release).
|
|
|
|
They can be used with native line endings.
We now have a shared folder with the dotnet repos and they have CRLF normalization enabled.
This difference leads to conflicts while applying changes from the dotnet repos to mono.
|
|
Add support for building Windows x64 fullaot version of winaot profile
that can be run on CI. Initial changes also add execution of mini regression
tests on CI. More tests will be added going forward and when having full
pass rate.
Add support for building Windows x64 fullaot+llvm version of winaot profile
that can be run on CI. Initial changes also add execution of mini regression
tests on CI. More tests will be added going forward and when having full
pass rate.
In order to get deterministic build results and working build on CI, we need
to setup a correct build environment for the MSVC builds. Since MSVC build is
currently run from cygwin, there are environment problems, both general
but also in our CI environment, since we add cygwin bin folder to system path
(needed by Jenkins plugin). When running more complex cmake builds like
BTLS and LLVM, this will cause problems picking up incorrect tools,
failing builds on CI.
Another problem is the AOT compilation using MSVC toolchain. In the
past CI used some "hard coded paths" to make sure clang.exe and link.exe was found.
This is not optimal and won't work when including LLVM as part of full AOT since
link.exe will need access to more of the full build environment setup by VS
development environments (like platform libraries).
In order to get a better build environment on CI this commit includes and enhance
a couple of build scripts used to run msbuild.exe and mono-sgen.exe (as AOT compiler)
in a VS development environment, isolate that build process from cygwin environment.
The build scripts will locate installed VS tooling, VS2015 build tools or VS dev env,
VS2017 build tools or VS dev env and use corresponding development environment
scripts as part of running msbuild.exe and mono-sgen.exe in AOT mode.
In order to make sure mono-sgen.exe as AOT compiler is run through these scripts
an additional environment variable MONO_EXECUTABLE_WRAPPER is introduced and used
in mono-wrapper when set. Without this indirection there will be problems on CI
tests since the environment is using MONO_EXECUTABLE and pass that into for example
test driver that run child processes of mono-sgen.exe, meaning that we can't
use scripts for MONO_EXECUTABLE, but splitting the MONO_EXECUTABLE to represent
mono runtime and have a MONO_EXECUTABLE_WRAPPER that could be a launch script
solves this issue.
This commit also includes several smaller fixes made to the generic
fullaot build infrastructure.
Fix additional msbuild arguments.
Add Mono.SIMD assembly to winaot profile.
Run msbuild.exe as part of .bat file.
|
|
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.
|
|
By default, all projects are build using "default" compiler based on source
file extension. There is a property in mono.props, MONO_COMPILE_AS_CPP
that could change this and build selected projects (eglib, libgcmonosgen,
libmini, libmono-dynamic, libmono-static, libmonodac, libmonoruntime,
libmonoutils, mono, monodis, monograph and pedump) using C++ compiler.
MONO_COMPILE_AS_CPP property could be set when calling msbuild
or through VS property manager IDE. Default value is false building using
"default" compiler (current behavior). When setting MONO_COMPILE_AS_CPP=true
the build prefix will be altered to make sure the C++ build gets its own build
folder, parallel to default build folders.
Example of building using C++ compiler from msbuild:
msbuild /p:PlatformToolset=v140 /p:Platform=x64 /p:Configuration=Release /p:MONO_TARGET_GC=sgen /p:MONO_COMPILE_AS_CPP=true msvc/mono.sln
|
|
Uses mono LLVM master branch, build using cmake and VisualStudio 2015/2017.
Commit adds support for AOT/Full AOT LLVM codegen for Windows x64 Visual Studio
build mono runtime. Normal configure/make using cygwin won’t support LLVM and will
trigger an error if configured.
In order to build using LLVM first mono LLVM master branch must be build using
static linked LLVM configuration (dynamic loading can be added later),
NOTE mono LLVM build needs to include the following commit,
https://github.com/mono/llvm/commit/9b92b4b87607e137266f84dc307181b8842fe54a
in order to successfully build on Windows x64.
Build mono LLVM branch using the following cmake configuration:
-DCMAKE_BUILD_TYPE=Release
-DLLVM_ENABLE_ZLIB=OFF
-DLLVM_TARGETS_TO_BUILD="X86"
-DCMAKE_CROSSCOMPILING=False
-DCMAKE_SYSTEM_NAME=Windows
Use cmake with -G "Visual Studio 14 2015 Win64" to generate VS 2015 x64
targets. NOTE, if mono runtime is build using VS 2017, then LLVM should
be build using the same VS version using -G "Visual Studio 15 2017 Win64"
To enable LLVM build in mono.sln, set MONO_ENABLE_LLVM to “true” and make
sure MONO_LLVM_INSTALL_DIR_PREFIX points to the install directory used in
LLVM build above, default msvc/dist/llvm. Above LLVM properties can also
be set if build using msbuild.
A sample LLVM configure script has been included in msvc/llvm-cmake-config.bat.
|
|
library support.
|
|
Make libmono-static lib file include all needed runtime libs making it easier to
link and distribute as part of Mono SDK.
Commit also updates linking of vcxprojs in mono.sln to use merged static lib.
|
|
additional test/debug projects. (#3420)
* Fixing linker warning when building libmono DLL.
After splitting mono runtime into a static library used when building libmono
DLL, we got a linker warning since there were no object files left in the
libmono project. There was also a sematic issue with the current organization
of DllMain since it is located in driver.c that will be compiled into the static
library and then consumed by the linker building the DLL. In cases where the
static library was consumed directly it would still include DllMain entry point.
By splitting the DllMain method implementation into a separate specific windows file
we can both resolve the linker warning and remove the DllMain method implementation from the static
library and only include it when building the libmono DLL.
* Visual Studio projects support to optimally link mono applications using static libmono library.
Added a new property, MONO_USE_STATIC_LIBMONO that can be used to link some
mono applications, for example mono(-sgen).exe, towards static version of libmono.
This gives us the option to build a binary without dependencies on other runtime binaries
minimizing what’s needs to be deployed in order to run mono. This in combination with static linked c-runtime
(another option available through a VS property) will produce a mono runtime binary without
addition dependencies except .NET assemblies deployed by mono runtime users.
The default is still using the dynamic version of libmono as before.
* Visual Studio project to test/debug testdriver tests from within Visual Studio.
Added an additional Visual Studio project preconfigured to run testdriver related tests
directly from within Visual Studio.
Commit also includes an additional configuration script that can be used test projects in order
to setup a mono config file. The testdriver project uses this to create a unique configuration
files pointing to the build libtest.dll for running configuration. The configuration file will then
be used when the tests are executed to make sure the correct libtest.dll for current build configuration
gets used when running test different tests from within the Visual Studio debugger.
The project comes with a number of user macros as well that can be used in order to tailor how the tests are run.
Most of the values are preconfigured and shouldn't need to be changed in order to use
current build. In order to change the test that is executed, use the following user macro
defined in mono-testdriver-test property sheet added to the project:
MONO_TESTDRIVER_RUN_TARGET
and point it to the assembly hosting the tests to execute from within Visual Studio.
* Visual Studio project to test/debug nunit tests from within Visual Studio.
Added an additional Visual Studio project preconfigured to run nunit related tests
directly from within Visual Studio.
The project comes with a number of user macros as well that can be used in order to tailor how the tests are run.
Most of the values are preconfigured and shouldn't need to be changed in order to use
current build. In order to change the test that is executed, use the following user macro
defined in mono-nunit-test property sheet added to the project:
MONO_NUNIT_RUN_TARGET
and point it to the assembly hosting the tests to execute from within Visual Studio.
There is also an additional user macro defined:
MONO_NUNIT_FIXTURE
This can be used to limit the number of nunit test run within a test suite.
|
|
naming for intermediate pdb files for exe/dll's.
All artifacts will now have the same name of their final pdb file as
the library/dll/exe target file name.
The problem with the naming turns out to be a problem in Visual Studio
when a exe/dll use the same name of its intermediate pdb files and final
pdb file. In that case the final pdb file produced by the linker will be
incorrect and not usable by the debugger. This was the reason for the initial
change, giving intermediate pdb files a different name. Moving back to the
default naming for intermediate pdb files for exe/dll's will give the same
effect (a different name) and since libraries are not affected by this
problem, libraries can use the target name for their pdb files as well.
|
|
All projects will inherit the RuntimeLibrary from mono.props where it now
can be controlled using a user property, MONO_USE_STATIC_C_RUNTIME.
|
|
naming conflicts when linking.
|
|
* Enabled build target suffix in order to lable a build (primarly for sgen).
* Enabled separate build tree.
* Dropped all sgen configurations, replaced by properties and target suffix.
* Fixed pdb naming of intermediate pdb files.
|
|
|
|
* Upgraded all projects to new vs2015 tool chain.
* Used mono.props through property manager instead of import.
* Fixed dependencies to be more explicitly in additional dependecies.
* Fixed error in mono.props, switched $ to % when referencing internal variables.
* Added property variables for includes and libraries, defined in mono.props.
|
|
Some of the profiler projects are no longer needed since the corresponding pieces were removed.
Update sln to only build required projects by default and update configurations in projects.
Fixes the Win64 build on Jenkins.
|
|
OutDir/IntDir should end with trailing slash.
Don't override Linker OutputFile, instead copy jay via a PostBuildEvent to the correct dir.
|
|
|
|
This reverts commit 577482e3361159e0c4c4b0232a07195ba91335dd.
We dropped XP support (see https://github.com/mono/mono/pull/1723),
so this is no longer necessary.
|
|
They're basically the same thing, but v120 has DX10+ capabilities and v120_xp
is DX9 only. Since we're not building against DirectX, the difference is
purely academic - but changing the value to v120_xp means MSVC binaries run
on XP+, not Vista+
|
|
|
|
|
|
|
|
|
|
From:
https://github.com/mono/mono/pull/724
|
|
|
|
libmonoruntime seperate from libmono. Initial work on building sgen enabled mono with VS.
|
|
|
|
|
|
|
