Welcome to mirror list, hosted at ThFree Co, Russian Federation.

github.com/mono/mono.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2019-10-17Upgrade build scripts to support VS2019. (#17269)Johan Lorensson
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.
2019-03-06[gitattributes] Do CRLF normalization on sln/proj filesAlexander Köplinger
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.
2018-12-06Fix cross compile of libtest.Jay Krell
CC libtest_la-libtest.lo <inline asm>:37:2: error: instruction requires: Not 64-bit mode popl %eax ^ ... same error many times Fix ThisCall tests. Libtest.c needs to be C++ for Visual C+++ to accept __thiscall. gcc accepts __thiscall in C. Visual C++ only accepts __thiscall on member functions and function pointers, not globals. Gcc accepts on globals also. So test what we can. add extern C Limit thiscall testing to Win32, even if gcc has more support.
2017-10-03Restructure of mono.sln and build properties to better fix static/dynamic ↵lateralusX
library support.
2016-06-15Reverted back to use target name for library pdb files and defaultlateralusX
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.
2016-06-15Added support to select static or dynamic c-runtime based on user property.lateralusX
All projects will inherit the RuntimeLibrary from mono.props where it now can be controlled using a user property, MONO_USE_STATIC_C_RUNTIME.
2016-06-15Added suffix to intermediate build .pdb files in order to avoid potential ↵lateralusX
naming conflicts when linking.
2016-06-15Separate build tree and target suffix support.lateralusX
* 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.
2016-06-15Refactored VS depdencies + restructring VS solution and projects.lateralusX
2016-06-15Upgrade to vs2015 for native projects.lateralusX
* 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.
2015-08-06Fixed MSVC solution to compile straight out of the boxsdridi
2015-04-22Revert "[msvc] Change target MSVC release from v120 to v120_xp"Alexander Köplinger
This reverts commit 577482e3361159e0c4c4b0232a07195ba91335dd. We dropped XP support (see https://github.com/mono/mono/pull/1723), so this is no longer necessary.
2015-03-11[msvc] Change target MSVC release from v120 to v120_xpJo Shields
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+
2015-02-11[msvc] Upgrade the projects to require VS2013.João Matos
2014-10-10[runtime] More win32 build fixes.Zoltan Varga
2014-04-16[VS] Change the tools version back to v110 so it works with VS 2012.Rodrigo Kumpera
2013-10-18Fix MSVC build.Jonathan Lima
2013-08-12Fixed MSVC build, ported to Visual Studio 2012.Jonathan Lima
From: https://github.com/mono/mono/pull/724
2012-03-08Rework vcxproj files to match Makefile based build. Build libmonoutils and ↵Jonathan Chambers
libmonoruntime seperate from libmono. Initial work on building sgen enabled mono with VS.
2010-11-18Update vcxproj files.joncham
2010-09-11Add vcxproj filesjoncham