summaryrefslogtreecommitdiff
path: root/build.cmd
AgeCommit message (Collapse)AuthorFilesLines
2018-03-26Merge pull request #17226 from weshaggard/MergeRestoreTargetsWes Haggard1-1/+1
Merge various restore tasks into one Sync target
2018-03-26Work around Jenkins problem with large env varsBruce Forstall1-0/+5
Clear out `ghprbCommentBody` before msbuild is invoked, which can't deal with large environment variables.
2018-03-26Merge various restore tasks into one Sync targetWes Haggard1-1/+1
There were various restore targets happening independently when they should all be combined so the sync step can be independent from the build step. This change merges them together under the Sync target. In particular this moves RestoreOptData and RestoreNETCorePlatforms to be part of the sync step instead of being individually ran. Pass BuildType to sync commands so optdata gets restored correctly
2018-03-23Fix RestoreSources for optdata packagesWes Haggard1-1/+1
Pass unprocessed args to restore optdata step so it can override the sources when doing restore Handle prority as an unprocessed arg for the sync alias
2018-03-16This change make DacTableGen work for VS2017Vance Morrison1-17/+0
There was a issue (see https://github.com/dotnet/coreclr/issues/11305) where a tool used in the CoreCLR build called DacTableGen requires a old version of the msdia120.dll. The symptom is that this tool would fail with a class not registered errror. This tool comes from a very old nuget package microsoft.dotnet.buildtools.coreclr, which we no longer can build easly. Our guidance now is to move tools that are only used in one repository (like this one) out of nuget packages and simply build them as part of the build. This change makes a step in that direction. The DacTableGen code actually was already in the CoreCLR repo, so this change 1. Fixes the source of DacTableGen so that tool no longer needs a com object to be registered (but it DOES need msdia140.dll to be on the path. This is true for VS2017. 2. Turns on the build of DacTableGen 3. Change the build use the built DacTableGen (unless running on VS2017, in that case we use the the version in the tool package. 4.) Remove the hack that warns people to register msdia120 (since you don't need to anymore) There is also an unrelated addition to the docs. This change should still work for VS2015 (because it falls back to the old DacTableGen in that case) Finally we should move to using the Linux method of creating the DAC, and so all these tools and their nuget package can be removed.
2018-03-06Remove vs2015 build dependenciesjashook1-36/+2
2018-02-08Merge pull request #15673 from tannergooding/generatelayout-switchJarret Shook1-0/+19
Updating build.cmd to support 'generatelayout' when 'skiptests' is specified.
2018-01-10Fix incremental build by preventing nonchanging writes (#15817)Victor "Nate" Graf1-1/+1
Fix incremental build by preventing non-changing writes in generated ETW source code
2018-01-03Updating the build script to work when python is installed to a path ↵Tanner Gooding1-6/+6
containing a space. (#15707)
2018-01-02Retry: Enable EventPipe across Unix and Windows (#15611)Victor "Nate" Graf1-9/+61
* Revert "Revert "Enable EventPipe across Unix and Windows (#14772)" (#15609)" This reverts commit 302005ca8ae14eade37ddf4ac6e900617c1c166a. * Fix ARM build break * Use more explicit references to resolve build failures * Fix compat with python3 * Disable FeaturePerfTracing on Windows as it is not ready * Disable test for incomplete functionality * Fix test diabled patterns * Add license header * Use keyword types for managed code * Add message prefix * More precisly condition generation of eventing sources * Remove erroneously added changes
2017-12-30Updating build.cmd to support 'generatelayout' when 'skiptests' is specified.Tanner Gooding1-0/+19
2017-12-21Revert "Enable EventPipe across Unix and Windows (#14772)" (#15609)Victor "Nate" Graf1-43/+9
This reverts commit 7524d72d4f0f634fe5407280b83c25181dc8c556.
2017-12-20Enable EventPipe across Unix and Windows (#14772)Victor "Nate" Graf1-9/+43
* [squashed] most work complete to enable EventPipe on Windows * Eventpipe now builds on Windows * Ensure evevntpipe is intialized on Windows * Resolve the location of python from build.cmd * Ensure eventing files are generated when needed * moving linkage declaration to cmake * create new event from constructor * enable FEATURE_EVENT_TRACE and FEATURE_PERF_TRACE everywhere * [WIP] checkpoint in fixing contarct errors * add another possible python location * Fix double delete bug in EventPipeConfiguration destructor * Fix typo in function name * Revert changes to .gitgnore * bump to netstandard1.6 in preperation for new version of TraceEvent * Revert changes to groovy files * revert changes to perf-prep scripts * add common.h and use nothrow * Fix issue which was causing double delete of configprovider * Add new test utilizing TraceEvent * Remove accidentally added local directory reference * Add comment to explain the addition of misc/tracepointprovider.cpp * Add back sys.exit(0) and refactor * Change conditional to be more direct * Better handle NULL config * Initialize m_deleteDefered * Eliminate obsolete field * Fix spelling error * Fix nits * Make smaple progiler timing functions easier to read * Move projects back to netstandard1.4 * Incomplete improvements to EventPipeTrace test * Add event integrity checks to test * Clean up some left over code * Add EventSource based test * Remove unused PAL tests on Windows * Fix Linux build breaks * Minor changes to CMake files * Remove //HACK for hack that was previously removed * Fix formatting and negate a #ifdef * Add conditional to ensure PERFTRACING is not enabled without EVENT_TRACE * Take lock on EventPipeProvider and EventPipeConfiguration destruction * Load winmm.dll at runtime * Change function name and compile conditions * Move typedef into #ifndef * Use the correct config in setup * Change lifecycle managment of EventPipeConfiguration's configuration provider * Enable EventPipe tests pri0 and disable broken tests * Replace python3 only error with python2 compatable one * Make common.csproj build pri0 * Change TraceEvent version to 2.0.2 to match published verison * Address cross build failure * Remove use of undefined variable * Add crossgen fix to .cmd * Use more specific types to avoid marshalling errors * Use Assert-style statements and remove one check * Fix cross arch build * Fix flipped branch * Bring build.cmd changes to build.sh * Fix cmake writing * Revert "Bring build.cmd changes to build.sh" This reverts commit 893c6492548d8bc9859ebba5b1b810aa630fac63. * remove stdlib.h * Fix out of order null check
2017-12-13Get rid of old -altjitcrossgen argument now that CI has been updatedBruce Forstall1-3/+0
2017-12-12Make RyuJIT/arm32 the default arm32 JITBruce Forstall1-7/+10
RyuJIT/arm32 JIT is now named clrjit.dll (was named protojit.dll). arm32 LEGACY_BACKEND JIT is now named legacyjit.dll (was named clrjit.dll). Ubuntu and Tizen testing now use RyuJIT/arm32. Tests failing for legacy backend are now excluded with `LEGACYJIT_JITSTRESS_FAIL`, `LEGACYJIT_GCSTRESS_FAIL`, and `LEGACYJIT_FAIL`.
2017-11-13Enable RyuJIT/arm32 crossgen compilation of S.P.C.dllBruce Forstall1-6/+22
Currently, an ARM build and CI test run uses the legacy backend arm32 JIT. This change enables a build of RyuJIT/arm32 as a cross-targeting protojit.dll (altjit) in the cross tools (placed next to the x86 hosted crossgen.exe in the build), and uses that RyuJIT/arm32 cross-compiler to build System.Private.CoreLib.dll. The CI system when testing RyuJIT/arm32 will use this to test the crossgen'ed System.Private.CoreLib.dll built by RyuJIT/arm32 for all "arm" architecture jobs.
2017-11-09Fix build break when VS2015 is not installed. (#14948)Vance Morrison1-0/+17
* Fix build break when VS2015 is not installed. If you ONLY install VS2017 (now the common scneario) and build coreclr, it will fail with COM with a Class_Not_Registered error This is because a build-tools package is depending on an old COM object that has gone way in VS2017. While we sort getting a proper fix, this makes the work-around (which is registering the DLL by hand) discoverable. See https://github.com/dotnet/coreclr/issues/11305 for details. * typo
2017-11-04[Infrastructure] Use MSBuild v15 extension point to control CL parallelism, ↵Jacek Blaszczynski1-5/+5
abstract MSBuild /maxcpucount switch (#14578) This commit frees -ExtraParameters and uses MSBuild v15 extension point to control CL compiler parallelism. If MSBuild 15.0 is available - installed with Visual Studio 2017 - CL parallelism control is achieved by using extension point in Microsoft.Common.props file which allows to include Directory.Build.props - for details see [Microsoft.Common.props] [1] file in MSBuild repo. https://github.com/Microsoft/msbuild/blob/b38e4ceeaaec36c5237ae698041e9b9f18c84876/src/Tasks/Microsoft.Common.props#L36. MSBuild parallelism is controled via abstracted /maxcpucount command line switch which now is available as -MSBuildNodeCount pass through run.cmd/run.sh command line argument with default value equal to /maxcpucount (what defaults to number of logical processors). This allows to control MSBuild parallelism on all supported platforms. It is possible to control MSBuild parallelism programatically via MSBuild public API using MaxNodeCount properties available on the following APIs: Microsoft.Build.Evaluation.ProjectCollection.MaxNodeCount Microsoft.Build.Execution.BuildParameters.MaxNodeCount It's use in current build infrastructure would require creating unnecessary complexity and was ruled out.
2017-11-01Fix handling of `-priority=N` argument in build.cmdBruce Forstall1-0/+18
This argument is intended to be passed through directly to msbuild, but CMD doesn't handle `=` well, so using `-priority=N` with `build all` didn't work, for instance. Add special handling for the `-priority` argument to get around this problem.
2017-10-30Pass overridden packages directory to CMakeWes Haggard1-1/+2
2017-10-30Merge pull request #14712 from BruceForstall/VS2017Arm64Bruce Forstall1-6/+12
Allow building arm64 using VS2017 tools
2017-10-27Merge pull request #14515 from 4creators/masterWes Haggard1-17/+20
Fix Windows arm target cross build: detect prerelease VS2017, stay in repo root
2017-10-27[Local GC] Implement loader protocol for a standalone GC (#14663)Sean Gillespie1-16/+1
* First cut of the load protocol * Implement for non-standalone GC * Initial working implementation * First steps towards not using GetProcAddress when not using a standalone GC * Factor out loading routines into standalone and non-standalone cases * Remove the FEATURE_STANDALONE_GC_ONLY build * Code cleanup and comments * Comments for the version numbers * Use more appropriate type for config string * add GC_LOAD_STATUS_BEFORE_START to disambiguate failures before the start of the load and failures at the beginning of the load * FEATURE_STANDALONE_GC on by default * Implement YieldProcessor and MemoryBarrier for arm and arm64 * Remove missed FEATURE_STANDALONE_GC feature check
2017-10-26Allow building arm64 using VS2017 toolsBruce Forstall1-6/+12
VS2017 now includes ARM64 compilers. Change the build scripts so that the normal VC tools path is used for the builds for ARM64. However, if -toolset_dir is passed, then use the specified tools, as before.
2017-10-24Cleanup VsDevCmd.bat usage and improve build system messages to ease diagnosticsJacek Blaszczynski1-17/+17
2017-10-17Merge branch 'master' of https://github.com/dotnet/coreclrJacek Blaszczynski1-4/+14
2017-10-16Optimize native build of coreclr repo - 3x less memory , 11% build time ↵Jacek Blaszczynski1-3/+13
improvement (#14509) * Fix native build overparallelism * Fix native build parallelization problems * Allow overriding all build workaround parameters * Fix cleanup ommisions and local environment variable naming * Address code review feedback * Fix nul spelling and add standard message prefix * Simplify settings for CL compiler parallelism * Address code review feedback - remove whitespace
2017-10-16Fix Windows arm target cross build: detect prerelease VS2017, stay in repo rootJacek Blaszczynski1-3/+6
Fixes issue #14514 Arm Windows build was recently changed by adding vswhere based VS installation detection and earlier initialization of environment variables. For details see https://github.com/dotnet/coreclr/pull/14228/files#diff-02389dfac0a172ab80211625efc34318R22 This introduced the following problems: (i) inability to detect and use VS 15 preview releses, (ii) unexpected changes to working directory caused by VsDevCmd.bat script execution. These errors prevented an arm Windows build on my machine with different errors. In particular due to presence of arm tools only in preview version of VS the arm build consistently failed with CMake error "compiler unknown". Fixing of this problem unmasked second bug introduced by uncontrolled changes to build script working directory resulting in error: "Command line too long". Both problems are fixed in this PR. In addition in CrossArchBuild leg a new CMake custom argument is introduced which allows for selection of latest Windows 10 SDK available on machine directly by CMake. So far this define was present only in CoreCLR native build leg.
2017-10-12Allow not to build SOS.NETCore.dll (#14404)Jonghyun Park1-10/+15
* Allow not to build SOS.NETCore.dll * Automatically enable SkipSOS when a mscorlib option is given
2017-10-03Update Buildtools and Roslyn (#14228)Jose Perez Rodriguez1-0/+18
* Update Buildtools and Roslyn * Fixing importing of the roslyn files on msbuild 14.0 * Correctly looking for the latest VS Installation
2017-09-18Correct typos in reporoot/build.cmdJacek Blaszczynski1-9/+9
2017-09-14PGI: Load pgort<ver>.dll from the VS native tools env; do not `install` it ↵Daniel Podder1-0/+25
(#12581) On Windows, PGO instrumented builds (build.cmd release <arch> pgoinstrument) introduce a runtime dependency on pgort<ver>.dll for instrumented binaries. This DLL is distributed alongside the C++ compiler, and is made available via the native tools environment that ships with Visual Studio. Previously, we were using cmake to find and "install" this binary alongside the product when doing an instrumented build, so that the resulting bin\Product drop is free of any added external dependencies. However, this approach is fragile, and despite a best effort to make the implementation work across multiple VS releases, it already broke with VS 2017. To fix support for pgoinstrument on VS 2017, and to harden the implementation for future releases of VS, I'm removing the custom cmake install logic for the pgort DLL. Instead, we fall back to the officially supported method: load the correct (native tools) environment before invoking any command that uses an instrumented binary. This happens in one place in the build today--loading the JIT to crossgen System.Private.CoreLib.dll. Note that there's still an existing CLI/Setup bug that requires copying the pgort DLL. We're now doing it from within build.cmd, which is not nearly as fragile for this as cmake is. The workaround is also isolated, so when the referenced issue is fixed, the workaround (as documented) can simply be removed. Fixes #12347.
2017-08-30Remove -sequential build-flag (#13658)Omair Majid1-2/+0
The flag is not implemented anywhere and is completely ignored. Remove it form various help notices too. Fixes #12035
2017-08-25Scope environment variable settingBruce Forstall1-49/+103
The product and test build scripts invoke Visual Studio environment setting scripts several times during the build process. If doing a full cross architecture build including test build, it's as many as five times. These environment changes are cumulative. For the PATH variable, in particular, they can lead to a failure by exceeding the variable length limit. This seems to have been exacerbated by VS2017, which has very long paths, and for which many things are added to the PATH. Fix this by adding "setlocal" / "endlocal" around various sections of the scripts, so that the multiple calls to the environment script are not cumulative. (There is still some cumulative environment setting, as build.cmd calls VsDevCmd.bat, then if tests are being built, calls build-test.cmd, which also calls VsDevCmd.bat, and then possibly in addition calls vcvarsall.bat.) In addition, I simplified the code that sets up the msbuild logging parameters, so it is more readable, regular, and doesn't have so much repeated text.
2017-08-22Follow-up: Add enforce PGO to official builds (#13437)Victor "Nate" Graf1-4/+2
* Add variables to pipeline to enable enforcepgo for Release * Address review
2017-08-15Use dashes for build options (#13353)Vance Morrison1-22/+64
* Fix IndexOutOfRangeException in PayloadNames property If you pass an null payload using Write<T>, and in the EventListener then call PayloadNames, it will throw an IndexOutOfRangeException. It should just return null. This fixes this. * To be consistant with the other build.cmd files use - for options * Update docs to track change in option convention * Updated Unix script to use - for options. * Fix build break * Fix Whitespace (review feedback) * Another fix
2017-08-11Fix bug where whitespace breaks arg proccessing (#13320)Victor "Nate" Graf1-2/+5
* Fix bug where whitespace breaks arg proccessing * Fix whitespace proccessing bug in buil-text.cmd
2017-08-08Add build-time check to enforce PGO compilation for applicable DLL files ↵Victor "Nate" Graf1-0/+15
(#13258) * Added PGO execution verification script Added a script which can help verify whether or not PGO was used to compile PE files passed to it * Added target to enforce PGO compilation * Remove OS checking for enforcepgo
2017-07-07Revert change that always publish runtime layout (#12679)Yi Zhang (CLR)1-10/+0
2017-07-05Automatic build runtime layout when skipping tests (#12587)Yi Zhang (CLR)1-1/+11
2017-06-29Implement a /verbose flag to show the verbose output from crossgenBrian Sullivan1-0/+1
Added info on /verbose option to PrintUsageHelper() Convert printf(ascii) to wide strings in methodtable.cpp In build.cmd echo the crossgen /CreatePdb command line
2017-06-28Fix usage style.Pat Gavlin1-1/+1
2017-06-28Add a flag to build.{sh,cmd} to disable PGO.Pat Gavlin1-2/+7
This is helpful when performing JIT throughput measurements.
2017-06-07Only restore optdata for release builds (#12136)Daniel Podder1-1/+1
Avoid restoring optdata during a non-release build to minimize work done by build.sh/cmd. Fix #12126
2017-06-06Fix a bad merge for Windows standalone GC build (#12097)Sean Gillespie1-1/+1
2017-06-02Merge pull request #11699 from swgillespie/local-gc-branch-mergeSean Gillespie1-1/+7
Integration from dev/local-gc into master
2017-06-01Fix optdata restore functionality (#11935)Daniel Podder1-15/+14
Fix optdata restore functionality (#11935) Bring back optdata restore functionality following the move to 2.0 BuildTools and csproj-based CLI. Disable a harmless warning that broke the Linux build when consuming PGO counts due to -Werr. Fix #11796 for master
2017-06-01[Local GC] Scaffolding for loading a standalone GC (#11242)Sean Gillespie1-1/+7
* Configure the build system to build a CoreCLR capable of loading a standalone GC * Proto-implementation of dynamic GC loading * Build the GC with the VM's CMakeLists when doing a non-standalone build of the GC * [Local GC] Introduce a new feature define, FEATURE_STANDALONE_GC_ONLY, to be used by the CI to explicitly test local GC dynamic loading code paths * Fix the FEATURE_STANDALONE_GC_ONLY build for unix linkers * Rebase against master * Code review feedback: use the existing Unix exports file
2017-05-31Default to portable build in dev and official builds (#11985)Gaurav Khanna1-6/+1
2017-04-27Remove support for the x86 compat JIT from .NET Core.Pat Gavlin1-16/+1
These changes remove support for the x86 compat JIT from the build, the runtime, and the various perf/test scripts. Fixes #10733, #10734.