You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: docs/Adding-and-Updating-Dependencies.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -17,21 +17,21 @@ When adding new third party source dependencies please be very careful. Make sur
17
17
For example, a compiler's license might allow using it to compile our binary, but could be too restrictive to allow using its source code as part of the source code for a Dart SDK tool.
18
18
You must add a README.google if you check in third-party code, and note any local changes that have been applied to the code (see below for a template). Please cc dart-engprod@google.com on any third-party additions.
19
19
20
-
If you need to discuss license issues to make sure that a license is compatible please reach out to the legal team at google or talk with dart-engprod@google.com who can guide you to the right
20
+
If you need to discuss license issues to make sure that a license is compatible please reach out to the legal team at Google or talk with dart-engprod@google.com who can guide you to the right
21
21
person. Please refrain from speculating about licenses or make assumptions about what you may and may not do. If in doubt you should ask. If you are not a Google employee, contact a Dart team member who is.
22
22
23
23
We have a few rules to make sure that we can continue to build older versions of the SDK even if people delete or rewrite the history of repositories containing our third-party dependencies. There are two options for using repositories not hosted under https://github.com/dart-lang/ or https://github.com/google/:
24
24
25
25
1. Move it to the dart-lang org, or fork it there. Moving is better than forking since it avoids fragmented versions. If you do fork, please state in the README that this is used for pulling in as a DEPS, don't make local changes, and be sure to not publish to pub from the dart-lang fork.
26
26
27
-
2. Get the github repo mirrored on the dart.googlesource.com git server, and pull the dependency from there. This is the same way we do normal dependencies from dart-lang (see below), with one important exception:
27
+
2. Get the GitHub repo mirrored on the dart.googlesource.com git server, and pull the dependency from there. This is the same way we do normal dependencies from dart-lang (see below), with one important exception:
28
28
**For security reasons, all code pulled in to build the Dart SDK must be reviewed by Google employees, no matter where it comes from.** This means that you, or a Google employee, need to do an initial review of all code up to and including the commit you put in the DEPS file for all external packages.
29
29
30
30
All external packages must be pinned to a fixed commit (revision) in the DEPS file. If you update the DEPS to pin a newer version, you need to do another review of the changes between the two revisions. You can upload the review (of the changes in the dependency, not just the change in the DEPS file) to https://dart-review.googlesource.com for easy reviewing, and upstream any fixes in this dependency, before pinning the new version of the dependency.
31
31
32
-
For all dependencies on GitHub, we need a mirror. File a GitHub issue labeled `area-infrastructure` (https://dartbug.com) requesting a mirror. The mirrors go to `https://dart.googlesource.com/external/github.com/<org>/<repo>.git`. Once the mirror is set up, you can commit your changes to the DEPS file pointing at the github mirror.
32
+
For all dependencies on GitHub, we need a mirror. File a GitHub issue labeled `area-infrastructure` (https://dartbug.com) requesting a mirror. The mirrors go to `https://dart.googlesource.com/external/github.com/<org>/<repo>.git`. Once the mirror is set up, you can commit your changes to the DEPS file pointing at the GitHub mirror.
33
33
34
-
While you wait for the mirror to get set up, you can add the dependency to the DEPS file pointing directly to `http://github.com/<org>/<repo>.git`. This will let you develop against the dependency locally, but don't commit this.
34
+
While you wait for the mirror to get set up, you can add the dependency to the DEPS file pointing directly to `https://github.com/<org>/<repo>.git`. This will let you develop against the dependency locally, but don't commit this.
Copy file name to clipboardexpand all lines: docs/Branches-and-releases.md
+5-5
Original file line number
Diff line number
Diff line change
@@ -7,15 +7,15 @@
7
7
8
8
## Branches and work flows
9
9
10
-
We have a rather simple branch setup for the dart project. Normally, everything is developed on the master branch. Features that are not yet ready for prime time are hidden under a flag, and enabled when sufficient stability has been proven. We occasionally create feature branches for landing big and disruptive changes. In addition to that, we have our dev, beta, and stable branches used for releasing the sdk.
10
+
We have a rather simple branch setup for the dart project. Normally, everything is developed on the main branch. Features that are not yet ready for prime time are hidden under a flag, and enabled when sufficient stability has been proven. We occasionally create feature branches for landing big and disruptive changes. In addition to that, we have our dev, beta, and stable branches used for releasing the sdk.
Populated from the master branch via full pushes, usually twice a week. Only in emergencies are [cherry picks](Cherry-picks-to-a-release-channel.md) landed on the dev channel. Don't land CLs here. Released via [dev channel builds](https://dart.dev/tools/sdk/archive#dev-channel).
18
+
Populated from the main branch via full pushes, usually twice a week. Only in emergencies are [cherry picks](Cherry-picks-to-a-release-channel.md) landed on the dev channel. Don't land CLs here. Released via [dev channel builds](https://dart.dev/tools/sdk/archive#dev-channel).
Populated from the dev branch via full pushes, usually once a month, or via [cherry picks](Cherry-picks-to-a-release-channel.md). Don't land CLs here. Released via [beta channel builds](https://dart.dev/tools/sdk/archive#beta-channel).
@@ -27,9 +27,9 @@ In summary, we have in four main branches:
27
27
## Release cycle
28
28
Our normal release cycle is roughly 2 months long, but we don't make any guarantees, i.e., we may ship early if we feel that the stability is good or we may ship late if it is not. We don't normally follow a feature driven release cycle, but in some cases for larger changes to the language we may postpone a release to get all tools in sync.
29
29
30
-
During the entire cycle we do full merges of master to dev, basically releasing a green build from master on dev roughly twice a week. In case of bugs found quickly we do another full push.
30
+
During the entire cycle we do full merges of main to dev, basically releasing a green build from main on dev roughly twice a week. In case of bugs found quickly we do another full push.
31
31
32
-
We spend the last ~2 weeks of the cycle stabilizing the beta channel, starting with a full push of the latest dev release to beta. We only cherry picking critical fixes to the beta channel. People continue working on the master branch and dev releases will continue to be released. In this 2 week period we do multiple batches of cherry picks a week, and release those on the beta channel. We call this cherry-pick season.
32
+
We spend the last ~2 weeks of the cycle stabilizing the beta channel, starting with a full push of the latest dev release to beta. We only cherry picking critical fixes to the beta channel. People continue working on the main branch and dev releases will continue to be released. In this 2 week period we do multiple batches of cherry picks a week, and release those on the beta channel. We call this cherry-pick season.
33
33
34
34
Once we have something that looks good we merge it to stable and release it there. During the 2 months we do patch security, crash and critical bug releases on stable based on the latest stable version.
Copy file name to clipboardexpand all lines: docs/Building-the-Dart-VM-for-Android.md
+4-4
Original file line number
Diff line number
Diff line change
@@ -31,13 +31,13 @@ Run gclient sync to install the Android NDK and SDK. This may take 10 minutes or
31
31
32
32
# Building for Android
33
33
34
-
Once you’ve set up your build tree, you can build the Dart VM for Android by using the standard Dart build script with the addition of the --os android build flag:
34
+
Once you've set up your build tree, you can build the Dart VM for Android by using the standard Dart build script with the addition of the --os android build flag:
For convenience, add the path to the adb tool to your shell PATH:
43
43
@@ -91,7 +91,7 @@ or
91
91
92
92
`$ adb -s emulator-name emu kill ← if there is more than one emulator running`
93
93
94
-
## Running the Dart VM on an Android device ##
94
+
## Running the Dart VM on an Android device
95
95
96
96
First, make sure that the "USB Debugging" mode is enabled by navigating to Settings > Developer options > USB debugging. The box should be checked. You may need to have root on the device.
97
97
@@ -110,4 +110,4 @@ Now, you can copy dart and hello.dart to the device as above. If an emulator is
110
110
111
111
# Notes
112
112
113
-
The only effect of the “target_os” line in the Dart .gclient configuration file is to install the Android tools. Despite what the name “target_os” implies, the target_os line does not affect which OS is targeted. Therefore, once you’ve installed the Android tools you can (and should) leave the target_os = [“android”] line in place even when switching back and forth between building for Android and building for Linux.
113
+
The only effect of the `target_os` line in the Dart `.gclient` configuration file is to install the Android tools. Despite what the name `target_os` implies, the target_os line does not affect which OS is targeted. Therefore, once you've installed the Android tools you can (and should) leave the `target_os = ["android"]` line in place even when switching back and forth between building for Android and building for Linux.
[Install Visual Studio](https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#visual-studio) (2017 or newer). Make sure to install "Desktop development with C++" component.
53
+
[Install Visual Studio](https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md#visual-studio) (2017 or newer). Make sure to install "Desktop development with C++" component.
54
54
55
55
You must have Windows 10 SDK installed. This can be installed separately or by checking the appropriate box in the Visual Studio Installer.
56
56
57
-
The SDK Debugging Tools must also be installed. If the Windows 10 SDK was installed via the Visual Studio installer, then they can be installed by going to: Control Panel → Programs → Programs and Features → Select the “Windows Software Development Kit” → Change → Change → Check “Debugging Tools For Windows” → Change. Or, you can download the standalone SDK installer and use it to install the Debugging Tools.
57
+
The SDK Debugging Tools must also be installed. If the Windows 10 SDK was installed via the Visual Studio installer, then they can be installed by going to: Control Panel → Programs → Programs and Features → Select the "Windows Software Development Kit" → Change → Change → Check "Debugging Tools For Windows" → Change. Or, you can download the standalone SDK installer and use it to install the Debugging Tools.
58
58
59
-
Install Chromium's depot tools following [this](http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up) or [this](https://chromium.googlesource.com/chromium/src/+/master/docs/windows_build_instructions.md#install) instructions.
59
+
Install Chromium's depot tools following [this](http://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up) or [this](https://chromium.googlesource.com/chromium/src/+/main/docs/windows_build_instructions.md#install) instructions.
60
60
61
61
**Important:** If you are not a Googler make sure to set `DEPOT_TOOLS_WIN_TOOLCHAIN` system variable to `0` otherwise depot tools will attempt to pull down a Google-internal toolchain instead of using a local installation of Visual Studio.
62
62
63
-
<aname="source"/>
63
+
<aid="source"></a>
64
64
65
65
# Getting the source
66
66
@@ -93,7 +93,7 @@ Note: If you do not have emscripten, you can update your `.gclient` file to pull
The output will be in `out/ReleaseIA32/dart-sdk` on Linux and Windows, or `xcodebuild/ReleaseIA32/dart-sdk` on MacOS.
119
+
The output will be in `out/ReleaseIA32/dart-sdk` on Linux and Windows, or `xcodebuild/ReleaseIA32/dart-sdk` on macOS.
120
120
121
121
See also [Building Dart SDK for ARM or RISC-V](Building-Dart-SDK-for-ARM-or-RISC-V.md).
122
122
123
123
## Tips
124
124
125
125
By default the build and test scripts select the debug binaries. You can build and test the release version of the VM by specifying `--mode=release` or both debug and release by specifying `--mode=all` on the respective `build.py` and `test.py` command lines. This can be shortened to `-mrelease` or `-m release`, and the architecture can be specified with `--arch=x64` or `-a x64`, the default. Other architectures, like `ia32`, `arm`, and `arm64` are also supported.
126
126
127
-
We recommend that you use a local file system at least for the output of the builds. The output directory is `out` on linux, `xcodebuild` on Mac OS, and `build` on Windows. If your code is in some NFS partition, you can link the `out` directory to a local directory:
127
+
We recommend that you use a local file system at least for the output of the builds. The output directory is `out` on linux, `xcodebuild` on macOS, and `build` on Windows. If your code is in some NFS partition, you can link the `out` directory to a local directory:
128
128
```bash
129
129
130
130
$ cd sdk/
@@ -143,7 +143,7 @@ Your Visual Studio executable command may have a different name from the standar
143
143
144
144
## Building on Windows with Visual Studio 2015
145
145
Gyp should autodetect the version of Visual Studio you have, and produce solution files in the correct format.
146
-
If this is not happening, then set environment variable gyp\_msvs\_version to 2015.
146
+
If this is not happening, then set environment variable `gyp_msvs_version` to `2015`.
147
147
148
148
For example, this will produce Visual Studio 2015-compliant solution files:
149
149
```bash
@@ -244,7 +244,7 @@ Some common problems you might get when running tests for the first time:
244
244
245
245
* Other options include using ssh X tunneling (`ssh -Y`), NX, VNC, setting up `xhost` and exporting the DISPLAY environment variable, or simply running tests locally.
Copy file name to clipboardexpand all lines: docs/Cherry-picks-to-a-release-channel.md
+1-1
Original file line number
Diff line number
Diff line change
@@ -76,7 +76,7 @@ This is a patch release that:
76
76
...
77
77
```
78
78
79
-
Link to your cherry-pick request as subsequently filed below. You can upload the changelist again with the final link once the github issue has been filed. The cherry-pick request on github is often more useful for users than the original bug, since it explains the rationale concisely and links to the underlying bug for more information.
79
+
Link to your cherry-pick request as subsequently filed below. You can upload the changelist again with the final link once the GitHub issue has been filed. The cherry-pick request on GitHub is often more useful for users than the original bug, since it explains the rationale concisely and links to the underlying bug for more information.
80
80
81
81
If the cherry-pick is infrastructure only and is invisible to users, the `Changelog-Exempt: ...` footer exempts the change from the changelog requirement.
The handle_segv=0 is only crucial when running through the test suite, wherein several tests are expected to segfault, and will fail if ASan installs its own segfault handler.
53
+
The `handle_segv=0` is only crucial when running through the test suite, wherein several tests are expected to segfault, and will fail if ASan installs its own segfault handler.
0 commit comments