| Age | Commit message (Collapse) | Author |
|---|
|
Contributes to #17064
* Add System.Data.DataSetExtensions to mobile profiles
|
|
* [aotprof-tool] Initial import
Imported https://github.com/radekdoulik/aotprofile-tool and updated it
to use Mono.Profiler.Log
* [aotprof-tool] Added man page
* [aotprof-tool] Use the shortened name in README.md
|
|
|
|
* Remove nunit24 from mono build and tree
* More cleanup
* Fix build
* [csproj] Update project files
|
|
* Move drawing types for XI/XM/wasm/orbis/unreal to System.Drawing.Common
For XI/XM they were in Xamarin.iOS.dll/OpenTK-1.0.dll before.
For wasm/orbis/unreal we remove System.Drawing.dll from the profiles and
add the types to System.Drawing.Common.dll instead to align with the other
mobile profiles (only "net_4_x" and "build" still have System.Drawing.dll).
* Bump API snapshot submodule
* [csproj] Update project files
|
|
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.
|
|
Contributes to #7246
|
|
This should help get information on native crashes that happen in hard-to-debug environments.
To quote https://github.com/mono/mono/issues/10157 :
When a mono runtime is attached to a managed debugger and the debugged runtime is induced to cause a crash, the state of that crash is not communicated to the managed debugger. This, combined with the difficulty in having the debugged runtime both attached to the managed debugger and lldb, makes this type of crash difficult to interactively debug.
When the managed debugger is the only connection someone has with the runtime because it is embedded in a way that is resistant to unmanaged debugging (watchOS application on-device, for instance), this is an even more difficult problem.
By adding an SDB protocol event that sends a type of "runtime death" and a blob of opaque json (version dependent, no protocol guarantees), people can report these crashes without having to assist a mono runtime engineer in observing a crash on device.
In the case that spurious bugs in this manner are submitted, it will require less effort as well to spot stack frames that indicate misuse of mixed managed-unmanaged APIs (which offer the ability to drive a segfault or g_assert
|
|
Clean up facades to build remaining ones in parallel
|
|
|
|
<!--
Thank you for your Pull Request!
If you are new to contributing to Mono, please try to do your best at conforming to our coding guidelines http://www.mono-project.com/community/contributing/coding-guidelines/ but don't worry if you get something wrong. One of the project members will help you to get things landed.
Does your pull request fix any of the existing issues? Please use the following format: Fixes #issue-number
-->
|
|
and build more facades in parallel
|
|
* Remove use of sln dependencies and use csproj project references instead
* Rewrite jay.vcxproj so it builds correctly even without help from the sln file
* Force pre-build event to run after references are resolved. Change how culevel.exe path is computed to be more resilient.
* [csproj] Update project files
|
|
building using msbuild (#9859)
* Manually add a csproj file for cil-stringreplacer
Adjust trace level for genproj
* Manually add cil-stringreplacer to bcl.sln and set it as a dependency of corlib
* Fix typo
* Add post-build event to corlib that runs cil-stringreplacer on it in mscorlib mode
* [csproj] Update project files
|
|
of solution dependencies (#9670)
Using solution dependencies in ```bcl.sln``` seems flaky and seems like it might not establish the full ordering we need to ensure that ```Consts.cs``` exists before we build things that require it. Let's try using project references (where ```corlib.dll``` 'depends' on ```genconsts.exe```) instead. This should also insert the dependency for any project that includes Consts.cs instead of just corlib.
This PR also makes update-solution-files actually fail if ```genconsts.exe``` fails to build because it was driving me mad.
Part of #6886
|
|
This adds a simple script for generating Consts.cs that can run on Windows, and makes it a dependency of corlib.csproj in the BCL solution file. From my initial testing this will autogenerate Consts.cs if it's missing and then corlib will successfully build.
This (mostly?) addresses issue https://github.com/mono/mono/issues/6886.
This currently has an awkward dependency on ```winsetup.bat``` and I modified it slightly to make it clearer whether the batch file succeeded.
|
|
* [mono-api-diff] Moved mono-api-diff into its own tools directory
* [mono-api-diff] Making the requested changes
|
|
host platform (#8985)
* Update genproj makefile to include gensources
Update genproj argument parser to be more generous about displaying help
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint
* Fix rebase issue
* Checkpoint
* Checkpoint
* Fix built sources only being added to one profile
* Fix typo
* Checkpoint
* Fix indentation
* Use csc instead of mcs
* Checkpoint
* Fix BUILT_SOURCES only being handled for the first profile processed
* Checkpoint
* Checkpoint
* Strip double slashes from paths to fix spurious csproj change
* Checkpoint
* Checkpoint
* Checkpoint
* Checkpoint: Fix genproj compilation
* Checkpoint
* Checkpoint
* Checkpoint
* Fix crash when no targets were loaded (due to an error)
* Checkpoint
* Checkpoint
* Checkpoint
* Fix TryParseTargetInto bug
* Checkpoint
* Shuffle exclude logic around so that it works correctly during genproj diffing
* Remove gensources tracing
* Checkpoint
* Fix handling of oddball sources paths from executable.make
* Fix jay not being set to build
* Fix wrong slashes being used for embedded resource paths
* [csproj] Update project files
|
|
* [ci] Update csproj files during PRs
Similar to how API diff is done.
Replace EXTERNAL_DRAWING_FACADE in csproj in genproj
It'd embed the absolute path in the csproj, but we want the variable instead.
* [csproj] Update project files
|
|
|
