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-03Optional only build MSVC runtime using make file system on Windows. (#16915)Johan Lorensson
* Build MSVC only runtime using make file system. Add a new option to only build MSVC version of mono runtime and native tools, --enable-msvc-only. In the past, --enable-msvc build both mingw as well as MSVC runtime, this commit adds an option to only build MSVC version of runtime and native tools using make file system. Commit updates all native make file making sure mingw/gcc builds are not done if --enable-msvc-only has been used. It also makes sure we build and use MSVC based tools as part of build and tests. Result will be a build without any mingw/gcc artifacts, but where all existing make files still works with the MSVC build artifacts. This commits is also preparing to switch the .NETCore build over to use MSVC build runtime in order to get LLVM support, something that is currently only supported on Windows MSVC build. * Add link to mono-sgen.exe and clean windows binaries. * Fix failures in mono/tests test-aot on Windows. * Add fullaot-mixed tests on Windows x64. * Run msbuild in parallel. * Default to x64 mingw host on cygwin build.
2019-05-09Add log profiler support to Mono MSVC build.lateralusX
Several fixes to the log profiler in order to work on Windows. * Add new dynamic library project to build log profiler on Windows MSVC. * Fix dependecy between log profiler and Mono. * Rewrite command pipe logic on Windows since it's not supported to select on both sockets and pipes. * Several additional socket fixes needed for log profiler to work on Windows.
2019-03-27Delete monograph. Closes https://github.com/mono/mono/issues/7845Jo Shields
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-11-12Add support for LLVM integrated build as part of Visual Studio solutionlateralusX
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.
2018-10-15Add vcxproj to build btls as part of regular mono msvc build.lateralusX
2017-10-03Restructure of mono.sln and build properties to better fix static/dynamic ↵lateralusX
library support.
2017-03-22Windows msbuild triggers too much to rebuild.lateralusX
When building mono solution from Visual Studio it correctly handles incremental builds just rebuilding what's needed. When doing the same from msbuild it rebuilds to much. This happens due to two different issues. First, a change in winconfig.h setting up a define for corlib version was not included in our compare config file script, so diff was detected as a change in config file causing a replace of config.h triggering a complete rebuild. Second, once above was fixed there was still a rebuild of mini-amd64.c when not needed. This was due to a difference in how post build events are handled in Visual Studio and msbuild. Visual Studio will detect that the complete project won't need to be rebuild and then it doesn't trigger any of the events. msbuild on the other hand will trigger events even if nothing needs to be rebuild and that triggered creation of cpu-amd64.h that in turn will trigger rebuild of mini-amd64.c. Switching from post build event to a custom build step with proper input/output files will work as expected in both Visual Studio and msbuild. Commit also disables the build of test projects that are part of solution but won't provide any build output. These projects are mainly there to make launching of test configurations easier and doesn't need to be included in solution build.
2017-02-28Improve unwind support on Windows x64.lateralusX
This commit improves the unwind support on Windows x64 by implementing a number of missing features. It also adds support for out of proc function table callback module on older OS versions and switch to different function table methods (growable function tables) on Win8/Win2012Server and later OS versions. Commit aligns more to the windows x64 prolog/epilog ABI, but since mono uses negative offsets from frame pointer while x64 windows uses positive, it is not possible to do a 100% "correct" representation in the prolog, but if we don’t give the OS unwinder the full unwind metadata in the frame pointer use case, we can trick unwinder to do the right thing presenting correct callstacks in debuggers. Commit includes representation of windows unwind info in mono's unwind data using extensions to better integrate windows specific unwind info in areas currently not supported (like trampolines). It will also be easier to implement unwind info in full AOT objects in the future, if windows specific unwind data is included in mono’s unwind data structures. On Win8/Win2012Server and later OS versions, all function table data is registered using growable function tables giving full support for callstacks on live debug targets and crash dumps. On previous OS versions function table callbacks are used together with an out of proc module. This works for live debugging in WinDBG and Visual Studio (if right permissions are given to the debuggers to load out of proc unwind module). Crash dumps works as expected in WinDBG but currently not in Visual Studio for older OS versions using callback support. If that use case needs to be supported it needs to be solved in a separate PR, but since we support crash dumps in Visual Studio on later OS versions and in WinDBG on earlier, it is still possible to analyze crash dumps by picking the right tool. Debuggers needs some additional information to work with function table callbacks out of proc modules (NOTE, this is NOT needed on Win8/Win2012Server and later). WinDBG: To just do live debugging, it is possible to run the following command in WinDBG, settings set EngineInitialization.VerifyFunctionTableCallbacks=false To do crash dump analysis the following registry key needs to be set, HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\KnownFunctionTableDlls Add the full path to mono-2.0-dac-sgen.dll matching the mono-2.0-sgen.dll as a 32-bit REG_DWORD. NOTE, adding the registry key removes the need to set the setting. Visual Studio: To do live debugging, set the same registry key as WinDBG use case.
2016-12-28Fix build_init vcxproj to correctly detect changes in config.h.lateralusX
build_init project doesn't detect changes done in config.h. This is needed in order for build_init to replace config.h with winconfig.h and backup cygconfig.h. This is normally an issue if you do a reconfigure and build using make and then msbuild. The msbuild will then fail, since config.h is still the cygwin version. Solution is to do a rebuild all that will trigger build_init. This fix will make sure that build_init gets invoked if there has been a change to config.h. There was also a very old issue with the first copy of config.h -> cygconfig.h. This is only done if there is no cygconfig.h in the directory. This means that the cygconfig.h will not be update until deleted and a new build_init has been invoked. This fix will make sure cygconfig.h is always updated if config.h is the cygwin generated version (not already replaced with winconfig.h).
2016-08-20Visual Studio project updates and enhancements to support static libmono and ↵Johan Lorensson
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.
2016-08-17Visual Studio test/debug mono runtime utility projects.lateralusX
Added a couple of new/updated test/debug Visual Studio utility projects. These projects can be used to quicker get up to speed when there is a need to run/test/debug mono runtime tests inside Visual Studio debugger. Added utility projects can be used to run mini regression tests using JIT as well as compile/run full AOT:ed versions of mini regression tests or other assemblies. The different .prop files are also organized so they can be reused when adding additional run/test/debug projects going forward.
2016-07-06Added support to build mono runtime as a static library. (#3231)Johan Lorensson
libmono will use static library when building its dynamic library. This gives the option to build binaries that could link the static version of mono runtime or use the dynamic version of the same library. The default build binaries still link against the dynamic version of the runtime.
2016-06-15Fixes to default build/distribution location.lateralusX
2016-06-15Added regression tests as visual studio projects.lateralusX
* Added regression test running mono/mini --regression [regression_tests] * Added regression test running mono/mini --aot [regression_tests] * Added default debugging options to run regression tests from within visual studio debugger. * On new build system, setting up include folder if not availalble. All changes applies to debug/release 32/64 bit.
2016-06-15Added regression test project.lateralusX
* Updated vs project files to resolve winsock, winsock2 build dependecies. * Added vs project running basic mono-mini regression tests.
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-15Restructured build/package/install targets and split GC libraries.lateralusX
* Added package/install targets. * Moved sgen into separate library. * SGEN set as default GC for build (used GC controlled through mono.props).
2016-06-15Refactored VS depdencies + restructring VS solution and projects.lateralusX
2016-02-08[msvc] Fix Debug build by disabling outdated projects in slnAlexander Köplinger
2015-11-20[msvc] Remove outdated projects and configs to fix x64 buildAlexander Köplinger
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.
2015-10-16[msvc] Remove left over project guid from mono.slnAlexander Köplinger
The project was removed from the solution in 735fc51cc092ef89ca08b8304c582af0bf60b8e4, but one instance was missed. This should fix the Windows build on Jenkins.
2015-10-15Fix MSVC build after 16570265149730ec6a4760cc0fa34decc1a9d981Alexis Christoforides
2013-03-01Revert "Fix object::GetType when remoting is enabled."Rodrigo Kumpera
This reverts commit 93e2d1dc48339be472300910e9290939ee253177.
2013-03-01Fix object::GetType when remoting is enabled.Rodrigo Kumpera
2013-03-01Make x64 compilation work out of the boxTalAloni
Change the default projects that are compiled for x64
2012-08-31Add missing files and adjust linker settings for sgen targets of vcxproj files.Jonathan Chambers
2012-05-31Build Configuration: Don't build libmono to Release_SGen in x64 Release mode.Filip Lundgren
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.
2011-04-22Disable vtune profiler by default.joncham
2011-03-27VTune Amplifier XE 2011 plugin for MonoVirgile Bello
2011-02-24Don't build code analyst profiler by default.joncham
2011-02-23Add CodeAnalyst profiler and clean up vcxproj files.joncham
2010-12-29Build 'eglib' in the Win32|Release profile.Jonathan Pobst
2010-11-18Update vcxproj files.joncham
2010-09-11Update mono.sln for 2010joncham
2010-09-11Migrate vcproj files to VS2010joncham
2009-11-032009-11-02 Jonathan Chambers <joncham@gmail.com>Jonathan Chambers
* genmdesc.vcproj: Fix amd64 build. * libmono.vcproj: Fix amd64 build. * mono.vcproj: Fix amd64 build. * mono.sln: Fix amd64 build. svn path=/trunk/mono/; revision=145261
2009-10-152009-10-15 Jonathan Chambers <joncham@gmail.com>Jonathan Chambers
* profiler-cov.vcproj: Add project. * profiler-logging.vcproj: Add project. svn path=/trunk/mono/; revision=144223
2009-05-02Buidl jay as wellMiguel de Icaza
svn path=/trunk/mono/; revision=133377
2009-05-02Use new define: TARGET_X86 on VS as wellMiguel de Icaza
svn path=/trunk/mono/; revision=133372
2009-05-02Upgrade to 2008Miguel de Icaza
svn path=/trunk/mono/; revision=133341
2009-04-252009-04-24 Bill Holmes <billholmes54@gmail.com>Bill Holmes
Fixing the glib targets for Winx64. * libmono.vcproj, mono.vcproj: Correcting the ProgramDatabaseFile value for the Winx64 glib build. * mono.sln: Enabling the glib targets for Winx64. Code is contributed under MIT/X11 license. svn path=/trunk/mono/; revision=132622
2008-12-042008-12-04 Bill Holmes <billholmes54@gmail.com>Bill Holmes
* mono.sln : Removing monoburg from the solution. * libmono.vcproj : Removing files deleted from svn. * mono.def : Removing mono_burg* exports that no longer exist. Code is contributed under MIT/X11 license. svn path=/trunk/mono/; revision=120725
2008-11-072008-11-07 Bill Holmes <billholmes54@gmail.com>Bill Holmes
* winconfig.h : Removing HAVE_DIRENT_H, HAVE_STDINT_H, HAVE_VISIBILITY_HIDDEN, HAVE_ZLIB for the VC builds. * monoposixhelper.def, monoposixhelper.vcproj : added. * mono.sln : Adding the monoposixhelper project. Code is contributed under MIT/X11 license. svn path=/trunk/mono/; revision=118214
2008-11-072008-11-07 Bill Holmes <billholmes54@gmail.com>Bill Holmes
* test_eglib.vcproj : Adding unicode.c to the project. * mono.sln : Adding the correct dependencies for e-glib. * *.vcproj : Setting LinkLibraryDependencies=false for all projects and all configurations. Code is contributed under MIT/X11 license. svn path=/trunk/mono/; revision=118178
2008-06-022008-06-02 Bill Holmes <billholmes54@gmail.com>Bill Holmes
* mono.sln, libtest.vcproj: Adding libtest to the VS solution. libtest is needed for the marshaling tests. Contributed under MIT/X11 license. svn path=/trunk/mono/; revision=104678
2008-06-022008-06-02 Bill Holmes <billholmes54@gmail.com>Bill Holmes
* monodiet.vcproj, libgc.vcproj, test_eglib.vcproj, eglib.vcproj, teste.vcproj, genmdesc.vcproj, monoburg.vcproj, monograph.vcproj, pedump.vcproj, test-metadata.vcproj, libmono.vcproj, mono.sln, mono.vcproj, monodis.vcproj,test-invoke.vcproj Changes to the Visual Studio projects to unify the output directories for each project and configuration. Contributed under MIT/X11 license. svn path=/trunk/mono/; revision=104669
2008-04-162008-04-15 Jonathan Chambers <joncham@gmail.com>Jonathan Chambers
* mono.sln, libmono.vcproj, monoburg.vcproj, genmdesc.vcproj: Flush Win64 and eglib changes. Contributed under MIT/X11 license. svn path=/trunk/mono/; revision=100815
2008-03-102007-03-10 Bill Holmes <billholmes54@gmail.com>Bill Holmes
* generic-sharing.c: Including glib.h for the MSVC builds to define "inline" to "__inline" before including mono-membar.h. * mono-perfcounters.c: Adding HAVE_SYS_TIME_H check for MSVC builds. Rename "Unknown" to "CatTypeUnknown" to avoid name collisions for MSVC builds. * mono.sln: Fixing configuration list to build the correct targets for the specified configuration. * runburg.bat, runmdesc.bat: Changing the PATH environment variable assignment to the correct location. * libmono.vcproj: Adding missing files. Contributed under MIT/X11 license. svn path=/trunk/mono/; revision=97888