There are default settings that intend to hit the 'most cases' scenario. If all is going to plan, you should never need to specify any additional parameters. However
the script from stomping out any changes you have made in the working directory. Additionally, when things do go wrong (inevitably they will), this tool places a shell/batch script
within the working directory that contains the command line that failed. This is to enable the scenario where you want to 'drill into' a problem.
### EXAMPLES
The first time you run this tool HAS to be like this:
```
./cli.bootstrap.py
```
This will spawn a directory next to the bootstrap script, named after its runtime identifier (the runtime identifier is currently picked from the /os/release and we concatenate the
VERSION and VERSION_ID values). So on an AMD64 Ubuntu 16.04 machine, the RID is ubuntu.16.04-x64-dotnet
Any additional runs can be controlled via these command lines, and consequently, any additional runs are going to be in DevMode.
```
./cli.bootstrap.py -b corefx libuv
```
This will build only the corefx binaries and coreclr binaries, then patch the files.
If you want to prevent patching (for example, just to re-run a build):
```
./cli.bootstrap.py -b corefx coreclr -nopatch
```
Additionally, if you have a tarball of the files that you'd like to produce, consider:
__build_set__ is the space-delimited set of repositories to place. At the moment it is one of these {coreclr, corefx, core-setup, libuv}.
By default cli.bootstrap will pull in a pre-built tar file from the CLI repository and patch this. If you want to provide your own binaries to patch
(from dev builds or something), then specify a path (relative or absolute).
After you run the cli.bootstrap, you'll see a directory named after the Runtime Identifier (RID) next to the script, the directory tree looks like this (for example),