Add Unity files (unity-2017.4.2-mbe), commit hash f1b3cc1149819b54e13…

…232f1d359b14bc7ffd7a3

unity-2017.4.2-mbe/.editorconfig

@@ -0,0 +1,28 @@
+# see http://editorconfig.org/ for docs on this file
+
+root = true
+
+[*]
+end_of_line = lf
+trim_trailing_whitespace = false
+insert_final_newline = false
+indent_style = tab
+indent_size = 4
+
+# this VS-specific stuff is based on experiments to see how VS will modify a file after it has been manually edited.
+# the settings are meant to closely match what VS does to minimize unnecessary diffs. this duplicates some settings in *
+# but let's be explicit here to be safe (in case someone wants to copy-paste this out to another .editorconfig).
+[*.{vcxproj,vcxproj.filters,csproj,props,targets}]
+indent_style = space
+indent_size = 2
+end_of_line = crlf
+charset = utf-8-bom
+trim_trailing_whitespace = true
+insert_final_newline = false
+[*.{sln,sln.template}]
+indent_style = tab
+indent_size = 4
+end_of_line = crlf
+charset = utf-8
+trim_trailing_whitespace = true
+insert_final_newline = false

unity-2017.4.2-mbe/.gitattributes

@@ -0,0 +1,69 @@
+# ensure LF endings on all checkouts
+configure.ac	crlf=input
+config.rpath	crlf=input
+configure.host	crlf=input
+mkinstalldirs	crlf=input
+*.sh	crlf=input
+*.sources	crlf=input
+.gitattributes	crlf=input
+*akefile*	crlf=input
+
+# ensure native line endings on checkout
+*.c	crlf
+*.h	crlf
+*.cs	crlf
+*.il	crlf
+
+# don't do anything to line-endings.  Let CRLFs go into the repo, and CRLF on checkout
+*.bat	  	-crlf
+*.sln		-crlf
+*.*proj* 	-crlf
+*.xml 		-crlf
+
+# CRLF Handling
+# -------------
+#
+# The ideal situation would be to do no EOL normalization.  Each file
+# would have a default EOL, and tools on Windows and Linux would handle
+# both EOL formats.
+#
+# We're not in the ideal world.  A popular editor on Windows (possibly
+# Visual Studio) silently introduces EOL corruption -- it displays an
+# LF-file normally, but any newly added lines have CRLF.  On Linux,
+# Emacs and versions of VI handle LF-files and CRLF-files properly.
+# However, emacs doesn't like files with both LF and CRLF EOLs.  Editing
+# the file without additional action will increase the EOL corruption
+# in the file.
+#
+# Another vector for mixed EOLs is scripts.  We mostly don't have scripts
+# that add new lines -- so we rarely see this.  However, one major event
+# in the tree was the addition of copyright headers using a script.  That
+# script introduced EOL corruption.
+#
+# Any automated EOL normalization of files already in the repository will
+# cause difficulties in traversing histories, assigning blame, etc.  So, we
+# don't want to change what's in the repository significantly, even if it
+# causes trouble.
+#
+# What we do now:
+#
+# a) we ensure that there's no further corruption of LF-files.  So, we use
+#    git's 'crlf' attribute on those files to ensure that things are fine
+#    when we work on Windows.  We could use 'crlf=input', but it doesn't buy
+#    us much -- we might as well be working with consistent EOLs for files in
+#    working directories as well as in the repository
+#
+# b) if the file already of CRLFs, we don't do any normalization.  We use '-crlf'
+#    so that git doesn't do any EOL-conversion of the file.  As I said, this
+#    is mostly harmless on Linux.  We can't mark these files as 'crlf' or use
+#    the new (git 1.7.2) 'eol=crlf' attribute, since it changes the contents
+#    _inside_ the repository [1], and hence makes history traversal annoying.
+#    So, we live with occasional EOL corruption.
+#
+# c) We can handle mixed-EOL files on a case-by-case basis, converting them to
+#    LF- or CRLF-files based on which causes fewer lines to change
+#
+# d) We try to ensure no further headaches, by declaring EOL normalization on
+#    code files, and Unix-flavoured files, like shell-scripts, makefiles, etc.
+#
+# [1] GIT use LFs as the normalized internal representation.

unity-2017.4.2-mbe/.gitignore

@@ -0,0 +1,138 @@
+##############################################################################
+# General
+##############################################################################
+
+# OS junk files
+[Tt]humbs.db
+*.DS_Store
+
+# Visual Studio / MonoDevelop
+*.[Oo]bj
+*.exe
+*.dll
+*.pdb
+*.user
+*.aps
+*.pch
+*.vspscc
+*.vssscc
+*_i.c
+*_p.c
+*.ncb
+*.suo
+*.tlb
+*.tlh
+*.bak
+*.ilk
+*.log
+*.lib
+*.sbr
+*.sdf
+*.opensdf
+*.resources
+*.res
+ipch/
+obj/
+[Bb]in
+[Dd]ebug*/
+[Rr]elease*/
+Ankh.NoLoad
+*.gpState
+.vscode/
+*.exp
+
+# Unity build process files
+builds/
+ZippedClasslibs.tar.gz
+tmp/
+
+# Tooling
+_ReSharper*/
+*.resharper
+[Tt]est[Rr]esult*
+*.orig
+*.rej
+
+# NuGet packages
+!.nuget/*
+[Pp]ackages/*
+![Pp]ackages/repositories.config
+
+# Temporary Files
+~.*
+~$*
+
+# Autotools-generated files
+/Makefile
+Makefile.in
+aclocal.m4
+autom4te.cache
+/build/
+config.cache
+config.guess
+config.h
+config.h.in
+config.log
+config.status
+config.sub
+configure
+configure.scan
+cygconfig.h
+depcomp
+install-sh
+libtool
+ltmain.sh
+missing
+mkinstalldirs
+releases
+stamp-h
+stamp-h1
+stamp-h.in
+/test-driver
+*~
+*.swp
+*.o
+.deps
+
+# Libtool
+libtool.m4
+lt~obsolete.m4
+ltoptions.m4
+ltsugar.m4
+ltversion.m4
+
+# Dolt (libtool replacement)
+doltlibtool
+doltcompile
+
+# pkg-config
+*.pc
+
+# Emacs
+semantic.cache
+
+# gtags
+GPATH
+GRTAGS
+GSYMS
+GTAGS
+
+# Doxygen
+docs/doxygen*
+docs/perlmod*
+
+
+##############################################################################
+# Mono-specific patterns
+##############################################################################
+
+.dirstamp
+compile
+mono.h
+mono-*.tar.*
+tmpinst-dir.stamp
+msvc/scripts/inputs/
+extensions-config.h
+
+
+arm-apple-darwin10.h

unity-2017.4.2-mbe/.gitmodules

@@ -0,0 +1,64 @@
+[submodule "external/aspnetwebstack"]
+	path = external/aspnetwebstack
+	url = git://github.com/mono/aspnetwebstack.git
+[submodule "external/Newtonsoft.Json"]
+	path = external/Newtonsoft.Json
+	url = git://github.com/mono/Newtonsoft.Json.git
+[submodule "external/cecil"]
+	path = external/cecil
+	url = git://github.com/mono/cecil.git
+	branch = mono-2017-02
+[submodule "external/rx"]
+	path = external/rx
+	url = git://github.com/mono/rx.git
+	branch = rx-oss-v2.2
+[submodule "external/ikvm"]
+	path = external/ikvm
+	url = git://github.com/mono/ikvm-fork.git
+[submodule "external/ikdasm"]
+	path = external/ikdasm
+	url = git://github.com/mono/ikdasm.git
+[submodule "external/reference-assemblies"]
+	path = external/binary-reference-assemblies
+	url = git://github.com/mono/reference-assemblies.git
+[submodule "external/Lucene.Net.Light"]
+	path = external/Lucene.Net.Light
+	url = git://github.com/mono/Lucene.Net.Light.git
+[submodule "external/nunit-lite"]
+	path = external/nunit-lite
+	url = git://github.com/mono/NUnitLite.git
+[submodule "external/nuget-buildtasks"]
+	path = external/nuget-buildtasks
+	url = git://github.com/mono/NuGet.BuildTasks
+[submodule "external/buildtools"]
+	path = external/buildtools
+	url = git://github.com/mono/buildtools.git
+[submodule "external/cecil-legacy"]
+	path = external/cecil-legacy
+	url = git://github.com/mono/cecil.git
+	branch = mono-legacy-0.9.5
+[submodule "external/boringssl"]
+	path = external/boringssl
+	url = git://github.com/mono/boringssl.git
+	branch = mono
+[submodule "external/corefx"]
+	path = external/corefx
+	url = git://github.com/mono/corefx.git
+[submodule "external/bockbuild"]
+	path = external/bockbuild
+	url = git://github.com/mono/bockbuild.git
+[submodule "external/linker"]
+	path = external/linker
+	url = git://github.com/mono/linker.git
+[submodule "external/roslyn-binaries"]
+	path = external/roslyn-binaries
+	url = git://github.com/mono/roslyn-binaries.git
+[submodule "external/corert"]
+	path = external/corert
+	url = git://github.com/mono/corert.git
+[submodule "external/bdwgc"]
+	path = external/bdwgc
+	url = git://github.com/Unity-Technologies/bdwgc.git
+[submodule "external/libatomic_ops"]
+	path = external/libatomic_ops
+	url = https://github.com/Unity-Technologies/libatomic_ops.git

unity-2017.4.2-mbe/CONTRIBUTING.md

@@ -0,0 +1,73 @@
+Guidelines
+==========
+
+When contributing to the Mono project, please follow the [Mono Coding
+Guidelines][1].  We have been using a coding style for many years,
+please make your patches conform to these guidelines.
+
+[1]: http://www.mono-project.com/community/contributing/coding-guidelines/
+
+Etiquette
+=========
+
+In general, we do not accept patches that merely shuffle code around,
+split classes in multiple files, reindent the code or are the result
+of running a refactoring tool on the source code.  This is done for
+three reasons: (a) we have our own coding guidelines; (b) Some modules
+are imported from upstream sources and we want to respect their coding
+guidelines and (c) it destroys valuable history that is often used to
+investigate bugs, regressions and problems.
+
+License
+=======
+
+The Mono runtime, compilers, and tools and most of the class libraries
+are licensed under the MIT license. But include some bits of code
+licensed under different licenses. The exact list is [available here] (https://github.com/mono/mono/blob/master/LICENSE).
+
+Different parts of Mono use different licenses.  The actual details of
+which licenses are used for which parts are detailed on the LICENSE
+file in this directory.
+
+CLA
+=======
+
+Contributions are now taken under the [.NET Foundation CLA] (https://cla2.dotnetfoundation.org/). 
+
+Testing
+=======
+
+Pull requests go through testing on our [Jenkins server][2]. We will
+usually only merge a pull request if it causes no regressions in a
+test run there.
+
+When you submit a pull request, one of two things happens:
+
+* If you are a new contributor, Jenkins will ask for permissions (on
+  the pull request) to test it. A maintainer will reply to approve
+  the test run if they find the patch appropriate. After you have
+  submitted a few patches, a maintainer will whitelist you so that
+  all of your future pull requests are tested automatically.
+* If you are a well-known, whitelisted contributor, Jenkins will go
+  ahead and test your pull request as soon as a test machine is
+  available.
+
+When your pull request has been built, Jenkins will update the build
+status of your pull request. If it succeeded and we like the changes,
+a maintainer will likely merge it. Otherwise, you can amend your pull
+request to fix build breakage and Jenkins will test it again.
+
+[2]: http://jenkins.mono-project.com/
+
+# Inactivity
+
+Occasionally, a pull request sits for several months without any
+response from the author. This isn't necessarily an issue, but we may
+sometimes decide to close pull requests that have not seen any
+progress for a long time. This is in interest of keeping the pull
+request list clean so that other pull requests don't get lost in the
+clutter.
+
+If we do close your pull request due to inactivity, you're more than
+welcome to submit it anew after you address any comments or issues that
+were brought up on the original pull request.