commit | 5e0981041f5dc776541ccc474d410a8bdb49d75d | [log] [tgz] |
---|---|---|
author | Doug Ilijev <doilij@microsoft.com> | Sat Oct 15 01:26:56 2016 |
committer | Doug Ilijev <doilij@microsoft.com> | Sat Oct 15 01:26:56 2016 |
tree | c2aa6bb34ba2a9e627cd43a672938fe70a30ba6b | |
parent | f05c42e64c3b2d057ae1a52fe1917af26c9f2737 [diff] | |
parent | 60b8f018042a8055ce49fe656d8f9c8349bcaf10 [diff] |
[MERGE #1717 @dilijev] MicroBuild v2: Fix binary and package version metadata; refactor and improve scripts. Merge pull request #1717 from dilijev:microbuildv2 MicroBuild v2: Fix binary and package version metadata; refactor and improve scripts. Binary and Package Versions =========================== Binary File Version Metadata ---------------------------- Enables correct embedding of version string in file info. All binaries will now embed File Version metadata as follows: <MAJOR>.<MINOR>.<PATCH>.0 (<branch>:<hash>.<build_high>.<build_low>.<push_date>) Example: 1.2.1.0 (release/1.2:9786fcdbcaa6963a5ccc6648b7aa9bd9dd51d9ec.00008.12122.161007-1756) `MAJOR`, `MINOR`, and `PATCH` correspond to SemVer fields and will match the version of ChakraCore the package corresponds to. The fourth field would have been used to indicate security fixes (a.k.a. `QFE`) but because a fourth field is not allowed in NuGet package version numbers, but is standard for versions of binaries produced from VS projects, we are keeping the fourth field in the binary data and locking it to 0, and omitting it from NuGet package version numbers and release numbers from now on. Release NuGet Package Versions ------------------------------ The format of version strings for released NuGet packages will continue to be: Microsoft.ChakraCore.<MAJOR>.<MINOR>.<PATCH>.nupkg Example: Microsoft.ChakraCore.1.2.1.nupkg Preview NuGet Package Versions ------------------------------ The format of version strings for preview NuGet packages will now be: Microsoft.ChakraCore.<MAJOR>.<MINOR>.<PATCH>-<SPECIAL>.nupkg Where `<SPECIAL>` is: preview-<build_high>-<build_low> This solves the problem of getting enough information into the package preview version string (`<SPECIAL>`) to order builds correctly while still guaranteeing that we fit the requirements for the `<SPECIAL>` field: 1. It must start with a letter 2. It can only contain the characters [a-zA-Z0-9-] 3. It must be 20 characters or less Example: Microsoft.ChakraCore.1.2.1-preview-00008-12122.nupkg Miscellaneous Version-Related Changes ------------------------------------- Add `PATCH` version to `CommonDefines.h` so that it doesn't need to be manually coded into builds. (By reducing user intervention for package versions we make it more feasible to automatically release preview packages from multiple branches.) Extract `MAJOR`, `MINOR`, `PATCH`, and `QFE` version numbers from the source code by grepping for values of the `#defines` that correspond to those values. Refactorings and Script Parameters ================================== Merge `pogo_build.ps1` into `run_build.ps1`. Passing the required pogo-related flags to `run_build.ps1` produces a POGO build. No need to have separate scripts. Compute `ObjectDirectory` and use that for `Chakra.Generated.BuildInfo.props` unless `TF_BUILD_BUILDDIRECTORY` is specified in the PATH. Infer `$binpath`. For many parameters that were previously specified as environment variables from the environment of the build infrastructure, it is now possible to specify them as script parameters directly, where script parameters will take precedence over the values of the corresponding environment variables. This can be helpful when running scripts manually where you want to quickly experiment with the value of a variable without having to write it to the environment first. Since it is sometime valuable to get that variable from the environment, if the script parameter is unspecified, the value of the environment variable will be used instead. Additionally, if any parameter is unspecified by either script parameter or environment variable, a reasonable default is encoded in the script logic. In order of precedence, all values will be determined by checking for values in the following order, if applicable: 1. Script parameter 2. Environment variable 3. Script logic to retrieve value 4. Default value Add parameters with corresponding environment variables to specify skipping certain paths through the build scripts, which can save time when testing certain changes by ignoring expensive but unimportant parts of the builds. Specifying an environment value at the time the build is queued is easier than modifying the build definition, so adding the environment variable option adds convenience when testing with the production build definitions. * `run_build.ps1 -skipPogo` or set `SKIP_POGO` to a non-empty string will skip the POGO phase of the build, if it would have been a POGO build. Useful if the build binaries produced at the correct locations is enough and you're most interested in testing the non-POGO-related aspects of the build scripts. * `post_build.ps1 -skipTests` or set `SKIP_TESTS` to a non-empty string will skip running tests, which can be lengthy. This is useful if the quality of the binaries produced is not important and you're interested in testing other aspects of the build scripts. Miscellaneous ------------- Reduce dependencies on data from build server environments so that these scripts can be used to perform local builds. Update `UseValueOrDefault` to take any number of arguments. Reduce dependency on `locate_msbuild.ps1`. Add `$BuildSubtype` to 'not enough info' error. Check for the existence of `nuget.exe` before trying to invoke it. This helps when running in environments where NuGet is not installed or is not available. Can avoid errors related to NuGet package restore when running on a build server with a custom NuGet location and a specific NuGet Task separate from our scripts. Keeping the NuGet invocation in our scripts allows us to still do local builds without MicroBuild infrastructure configured on the dev machine (we don't take a hard dependency on the aforementioned NuGet Task.
ChakraCore is the core part of Chakra, the high-performance JavaScript engine that powers Microsoft Edge and Windows applications written in HTML/CSS/JS. ChakraCore supports Just-in-time (JIT) compilation of JavaScript for x86/x64/ARM, garbage collection, and a wide range of the latest JavaScript features. ChakraCore also supports the JavaScript Runtime (JSRT) APIs, which allows you to easily embed ChakraCore in your applications.
You can stay up-to-date on progress by following the MSEdge developer blog.
Debug | Test | Release | |
---|---|---|---|
x86 | |||
x64 | |||
arm |
Above is a table of our rolling build status. We run additional builds on a daily basis. See Build Status for the status of all builds.
If you believe you have found a security issue in ChakraCore, please share it with us privately following the guidance at the Microsoft Security TechCenter. Reporting it via this channel helps minimize risk to projects built with ChakraCore.
You can build ChakraCore on Windows 7 SP1 or above, and Windows Server 2008 R2 or above, with either Visual Studio 2013 or 2015 with C++ support installed. Once you have Visual Studio installed:
git clone https://github.com/Microsoft/ChakraCore.git
Build\Chakra.Core.sln
in Visual StudioMore details in Building ChakraCore.
Once built, you have a few options for how you can use ChakraCore:
Build\VcBuild\bin\[platform+output]
(eg. Build\VcBuild\bin\x64_debug
)A note about using ChakraCore: ChakraCore is the foundational JavaScript engine, but it does not include the external APIs that make up the modern JavaScript development experience. For example, DOM APIs like document.write()
are additional APIs that are not available by default and would need to be provided. For debugging, you may instead want to use print()
.
Contributions to ChakraCore are welcome. Here is how you can contribute to ChakraCore:
Please refer to Contribution guidelines and the Code of Conduct for more details.
For details on our planned features and future direction please refer to our roadmap.
For questions about ChakraCore, you can reach us on Gitter or open an issue and prefix the issue title with [Question]. See Question tag for already-opened questions.