Skip to content

Commit

Permalink
Update README.md (dotnet#33995)
Browse files Browse the repository at this point in the history
Add missing articles ("the") to README.md
  • Loading branch information
RobertHenry6bev committed Mar 24, 2020
1 parent b159b37 commit 7f7251d
Showing 1 changed file with 6 additions and 6 deletions.
12 changes: 6 additions & 6 deletions docs/workflow/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -12,7 +12,7 @@ The repo can be built for the following platforms, using the provided setup and
| ARM64 | ✔ | ✔ | | |
| | [Requirements](requirements/windows-requirements.md) | [Requirements](requirements/linux-requirements.md) | [Requirements](requirements/macos-requirements.md) |

Before proceeding further, please click on the link above that matches your machine and ensure you have installed all the prerequisites for build to work.
Before proceeding further, please click on the link above that matches your machine and ensure you have installed all the prerequisites for the build to work.

## Concepts

Expand Down Expand Up @@ -48,22 +48,22 @@ A quick reminder of some concepts -- see the [glossary](../project/glossary.md)

* **Debug Configuration** -- Non-optimized code. Asserts are enabled.
* **Checked Configuration** -- Optimized code. Asserts are enabled. Only relevant to CoreCLR runtime.
* **Release Configuration** -- Optimized code. Asserts are disabled. Runs at best speed, and suitable for performance profiling. You will have limited debugging experience.
* **Release Configuration** -- Optimized code. Asserts are disabled. Runs at the best speed, and suitable for performance profiling. You will have limited debugging experience.

When we talk about mixing configurations, we're discussing following sub-components:
When we talk about mixing configurations, we're discussing the following sub-components:

* **Runtime** is the execution engine for managed code and there are two different implementations available. Both are written in C/C++, therefore, easier to debug when built in a Debug configuration.
* CoreCLR is comprehensive execution engine which if build in Debug Configuration it executes managed code very slowly. For example, it will take a long time to run the managed code unit tests. The code lives under [src/coreclr](../../src/coreclr).
* CoreCLR is the comprehensive execution engine which if build in Debug Configuration it executes managed code very slowly. For example, it will take a long time to run the managed code unit tests. The code lives under [src/coreclr](../../src/coreclr).
* Mono is portable and also slimmer runtime and it's not that sensitive to Debug Configuration for running managed code. You will still need to build it without optimizations to have good runtime debugging experience though. The code lives under [src/mono](../../src/mono).
* **CoreLib** (also known as System.Private.CoreLib) is the lowest level managed library. It has a special relationship to the runtimes and therefore it must be built in the matching configuration, e.g., if the runtime you are using was built in a Debug configuration, this must be in a Debug configuration. The runtime agnostic code for this library can be found at [src/libraries/System.Private.CoreLib/src](../../src/libraries/System.Private.CoreLib/src/README.md).
* **Libraries** is the bulk of the dlls that are oblivious to the configuration that runtimes and CoreLib were built in. They are most debuggable when built in a Debug configuration, and, happily, they still run sufficiently fast in that configuration that it's acceptable for development work. The code lives under [src/libraries](../../src/libraries).

### What does this mean for me?

At this point you probably know what you are planning to work on primary: the runtimes or libraries.
At this point you probably know what you are planning to work on primarily: the runtimes or libraries.

* if you're working in runtimes, you may want to build everything in the Debug configuration, depending on how comfortable you are debugging optimized native code.
* if you're working in libraries, you will want to use debug libraries with release version of runtime and CoreLib, because the tests will run faster.
* if you're working in libraries, you will want to use debug libraries with a release version of runtime and CoreLib, because the tests will run faster.
* if you're working in CoreLib - you probably want to try to get the job done with release runtime and CoreLib, and fall back to debug if you need to. The [Building Libraries](building/libraries/README.md) document explains how you'll do this.

Now you know about configurations and how we use them, you will want to read how to build what you plan to work on. Pick one of these:
Expand Down

0 comments on commit 7f7251d

Please sign in to comment.