-
Notifications
You must be signed in to change notification settings - Fork 5.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add a build from source section #2014
Conversation
…ing recommendations
… optional packages.
…otnet/build-from-source
@bleroy, thanks for signing the contribution license agreement. We will now validate the agreement and then the pull request. |
docs/core/building/index.md
Outdated
|
||
The build currently depends on Git, CMake, Python and a C++ compiler. | ||
Once these prerequisites are installed, the CLR is built by invoking the 'build' script (`build.cmd` or `build.sh`) at the base of the | ||
repository. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What repository? Shouldn't there be a link to https://github.com/dotnet/coreclr/ somewhere at the start of this section?
docs/core/building/index.md
Outdated
In addition, by default the build will not only create the runtime executables, but it will also | ||
build all the tests. There are quite a few tests so this does take a significant amount of time | ||
that is not necessary if you want to experiment with changes. | ||
You can submit the building of the tests with the 'skiptests' argument to the build script. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it's me not being a native speaker, but I don't understand how does "submit" make sense here.
docs/core/building/index.md
Outdated
that is not necessary if you want to experiment with changes. | ||
You can submit the building of the tests with the 'skiptests' argument to the build script. | ||
|
||
In order to get a build as quickly as possible type the following (using `\` as the directory separator, use `/` on Unix machines) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just replacing \
with /
is not enough. ./build
won't work on Unix, ./build.sh
is needed.
docs/core/building/index.md
Outdated
|
||
### Building the CLI | ||
|
||
## Prerequisites |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This heading has the wrong level, it should be ####
, not ##
.
Also, the actual build instructions don't have their own heading, so it looks like they are part of Prerequisites, which is wrong.
docs/core/building/index.md
Outdated
This is the technique that all the tests in the repo use, and is useful for quick local 'edit-compile-debug' loop (e.g. preliminary unit testing). | ||
See [Executing .NET Core Apps with CoreRun.exe](https://github.com/dotnet/coreclr/blob/master/Documentation/workflow/UsingCoreRun.md) for details on using this technique. | ||
|
||
### Building the CLI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly to CLR above, I think there should be a link to the cli repo here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
first set of comments. more coming later if needed...
ms.assetid: 71b9d722-c5a8-4271-9ce1-d87e7ae2494d | ||
--- | ||
|
||
.NET Core distribution packaging |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we use #
for all headings
.NET Core distribution packaging | ||
================================ | ||
|
||
As .NET Core becomes available on more and more platforms, thanks to the efforts of dedicated contributors, it is useful to provide guidelines on how to package, name, and version it, in order to ensure a consistency of experience no matter where you choose to run .NET. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks to the efforts of dedicated contributors seems like content that would be in a blog post not on official docs
Suggested rewriting:
As .NET Core becomes available on more and more platforms, it's useful to learn how to package, name, and version it, in order to ensure a consistent experience no matter where you choose to run .NET.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean just that one paragraph, right?
================================ | ||
|
||
As .NET Core becomes available on more and more platforms, thanks to the efforts of dedicated contributors, it is useful to provide guidelines on how to package, name, and version it, in order to ensure a consistency of experience no matter where you choose to run .NET. | ||
This document provides such guidelines. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Remove this.
As .NET Core becomes available on more and more platforms, thanks to the efforts of dedicated contributors, it is useful to provide guidelines on how to package, name, and version it, in order to ensure a consistency of experience no matter where you choose to run .NET. | ||
This document provides such guidelines. | ||
|
||
What .NET Core is made of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This title is a bit strange. How about .NET Core components?
|
||
.NET Core is made of three major parts that need to be packaged: | ||
|
||
1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that is not a strict requirement. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is muxer a common word? for me, it just adds confusion here to add that aka but it could just be me
we style paths with italic and use contractions:
that is not -> that isn't
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's used in some contexts, so it's useful to mention that it is the same thing. This was originally added based on feedback.
.NET Core is made of three major parts that need to be packaged: | ||
|
||
1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that is not a strict requirement. | ||
2. **The framework** is made of a runtime and supporting managed libraries. A framework may be installed as part of an application, or as a shared framework in a central location that can be re-used by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host will roll forward across patch versions, so if an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it will be launched against 1.0.4. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A framework may -> The framework may
avoid future tense. For example:
The host will roll forward -> The host rolls forward
and probably better to break this sentence in two as well.
|
||
1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that is not a strict requirement. | ||
2. **The framework** is made of a runtime and supporting managed libraries. A framework may be installed as part of an application, or as a shared framework in a central location that can be re-used by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host will roll forward across patch versions, so if an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it will be launched against 1.0.4. | ||
3. **The SDK** (also sometimes referred to as "the tooling") is a set of managed tools that can be used to write and build .NET Core libraries and applications. This includes the CLI, MS Build and associated build tasks and targets, NuGet, new project templates, etc. It is possible to have multiple SDKs on a machine (in order, for example, to allow for building projects that explicitly require an older version), but the recommendation is to use the latest available tools whenever possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also sometimes referred to as -> also known as
MS Build -> MSBuild
It is possible -> It's possible
use the latest available tools whenever possible: wouldn't the support come into play here? LTS and Current?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
use the latest available tools whenever possible: wouldn't the support come into play here? LTS and Current?
Only for the runtime. I don't think that would apply to the SDK.
Recommended package names | ||
------------------------- | ||
|
||
These are recommendations, and a specific package maintainer may choose to diverge from it, for example based on different tradition of the specific distro they're targeting. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Suggested rewriting:
The following is our recommendation for package names. A package maintainer may choose to diverge from it based on various reasons, such as, a different tradition of the specific distribution they're targeting.
@@ -0,0 +1,69 @@ | |||
--- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
avoid ing on file and folder names for SEO purposes (we were not following guidelines earlier). probably packaging is ok in this scenario but building should be build
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The topics look good but I still have some more comments. If you prefer, I can make some of the changes I'm requesting on your behalf. Not sure if I can rename the building folder to remove the ing though. It's an SEO recommendation. If you'd like me to make the changes on your behalf, just let me know if you disagree with any of my comments. A lot of my comments are trying to make the topic more concise, to have a better flow or to follow style guide rules.
@@ -0,0 +1,63 @@ | |||
--- | |||
title: .NET Core distribution packaging | |||
description: .NET Core distribution packaging |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
needs to be different than title. It's what the search engine will display in search results. For example:
Learn how to package, name, and version .NET Core for ...
title: .NET Core distribution packaging | ||
description: .NET Core distribution packaging | ||
keywords: .NET, .NET Core, source, build | ||
author: beleroy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
bleroy is your GH alias
|
||
# .NET Core distribution packaging | ||
|
||
As .NET Core becomes available on more and more platforms, it's useful to learn how to package, name, and version it, in order to ensure a consistent experience no matter where you choose to run .NET. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
consider breaking the first sentence in two.
also the article should make clear who is your target audience and what's the goal of learning this. who this article is useful for? I think it should be stated in this paragraph.
.NET Core is made of three major parts that need to be packaged: | ||
|
||
1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that isn't a strict requirement. | ||
2. **The framework** is made of a runtime and supporting managed libraries. The framework may be installed as part of an application, or as a shared framework in a central location that can be re-used by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host rolls forward across patch versions. If an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it's launched against 1.0.4. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-used -> reused
|
||
1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that isn't a strict requirement. | ||
2. **The framework** is made of a runtime and supporting managed libraries. The framework may be installed as part of an application, or as a shared framework in a central location that can be re-used by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host rolls forward across patch versions. If an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it's launched against 1.0.4. | ||
3. **The SDK** (also known as "the tooling") is a set of managed tools that can be used to write and build .NET Core libraries and applications. This includes the CLI, MSBuild and associated build tasks and targets, NuGet, new project templates, etc. It's possible to have multiple SDKs on a machine (in order, for example, to allow for building projects that explicitly require an older version), but the recommendation is to use the latest available tools whenever possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in order, for example, to allow for building -> for example, to build
do we also need to make it clear that you should use the latest version of the released tools (vs. preview)?
docs/core/building/index.md
Outdated
|
||
#### Prerequisites | ||
|
||
In order to build .NET Command Line Interface, you need the following installed on you machine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Command Line Interface -> CLI
docs/core/building/index.md
Outdated
|
||
The source code for the .NET Core CLI can be found in [the `dotnet/cli` repository on GitHub](https://github.com/dotnet/cli/). | ||
|
||
#### Prerequisites |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you didn't add a section to the previous one. I think you can just list them without a heading.
docs/core/building/index.md
Outdated
- Xcode | ||
- OpenSSL | ||
|
||
#### building the CLI |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
then you can remove this
docs/core/building/index.md
Outdated
|
||
#### building the CLI | ||
|
||
In order to build, run `build.cmd` or `build.sh` from the root depending on your OS. If you don't want to execute tests, run `build.cmd /t:Compile` or `./build.sh /t:Compile`. To build the CLI in macOS Sierra, you need to set the DOTNET_RUNTIME_ID environment variable by running `export DOTNET_RUNTIME_ID=osx.10.11-x64`. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
depending on your OS: I'd actually say which one you use in Windows vs. Linux/macOS
docs/core/building/index.md
Outdated
|
||
#### Using your build | ||
|
||
Use `artifacts/{RID}/stage2/dotnet` to try out the `dotnet` command. You can also add `artifacts/{os}-{arch}/stage2` to the PATH if you want to use the build output when invoking `dotnet` from the current console. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Use artifacts/{RID}/stage2/dotnet
-> what does this mean?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AFAIK, this is the actual path to the dotnet executable, except {RID}
is a placeholder depends on your OS (including the specific version of a specific Linux distro) and architecture.
Thanks for the great feedback. Hopefully I addressed it all. |
@mairaw are there any remaining issues on this PR? |
I'll start the review now but I already see that the folder hasn't been changed from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. Ran our terminology tool on these articles. I'm calling out the main suggestions.
@@ -0,0 +1,63 @@ | |||
--- | |||
title: .NET Core distribution packaging | |||
description: Learn how to package, name, and version .NET Core distribution packages |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add period in the end
* `dotnet-sdk-[major].[minor]`: new patch versions update the package, but new minor or major versions are separate packages. | ||
* `dotnet-lts`: `update` rolls forward major, minor, and patch versions. | ||
|
||
Those are recommendations, and each distro is free to choose what versions to offer, and when. For example, a distro that values stability more than being up to date may choose to release only versions that snap with the LTS release train. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
up to date -> up-to-date
Those are recommendations -> This topic has presented our recommendations for ... however each distro is free to choose what versions to offer and when.
|
||
Some maintainers may choose to provide additional packages such as: | ||
|
||
* `dotnet-lts`: the latest "Long-Term Support" version of the shared framework. [LTS and Current release trains](~/docs/core/versions/lts-current.md) correspond to different cadences at which .NET Core gets released. Users have a choice of adopting one or the other train, based on how often they are willing to update. This is a concept that is also tied to support levels, so it may or may not make sense depending on the distro being considered. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
latest "Long-Term Support" -> latest Long-Term Support (LTS)
.NET Core is made of three major parts that need to be packaged: | ||
|
||
1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that isn't a strict requirement. | ||
2. **The framework** is made of a runtime and supporting managed libraries. The framework may be installed as part of an application, or as a shared framework in a central location that can be reused by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host rolls forward across patch versions. If an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it's launched against 1.0.4. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's launched -> the app is
|
||
1. **The host** (also known as the "muxer") has two distinct roles: activate a runtime to launch an application, and activate an SDK to dispatch commands to it. The host is a native executable (`dotnet.exe`) and its supporting policy libraries (installed in `host/fxr`). It's built from the code in the [`dotnet/core-setup`](https://github.com/dotnet/core-setup/) repository. There is typically only one host on a given machine, although that isn't a strict requirement. | ||
2. **The framework** is made of a runtime and supporting managed libraries. The framework may be installed as part of an application, or as a shared framework in a central location that can be reused by multiple applications. There may be any number of shared frameworks installed on a given machine. Shared frameworks live under `shared/Microsoft.NETCore.App/<version>`. The host rolls forward across patch versions. If an application targets `Microsoft.NETCore.App` 1.0.0, and only 1.0.4 is present, it's launched against 1.0.4. | ||
3. **The SDK** (also known as "the tooling") is a set of managed tools that can be used to write and build .NET Core libraries and applications. This includes the CLI, MSBuild and associated build tasks and targets, NuGet, new project templates, etc. It's possible to have multiple SDKs on a machine (for example, to build projects that explicitly require an older version), but the recommendation is to use the latest released tools. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This includes the CLI, MSBuild and -> The SDK includes the CLI, MSBuild, and
https://microsoft-ce-csi.acrolinx.cloud/htmldata/en/rules/help/use_this_that_these_those_with_noun.html
https://microsoft-ce-csi.acrolinx.cloud/htmldata/en/rules/help/use_serial_comma.html
docs/core/building/index.md
Outdated
|
||
2. **Use corerun.exe to run an application using unpackaged Dlls**. | ||
This repository also defines a simple host called corerun.exe that does NOT take any dependency on NuGet. | ||
This host has to be told where to get the necessary DLLs you actually use, and you have to manually gather them together. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you simplify this sentence? Maybe "You need to tell the host where to get the required DLLs..."
docs/core/building/index.md
Outdated
2. **Use corerun.exe to run an application using unpackaged Dlls**. | ||
This repository also defines a simple host called corerun.exe that does NOT take any dependency on NuGet. | ||
This host has to be told where to get the necessary DLLs you actually use, and you have to manually gather them together. | ||
This is the technique that all the tests in the repo use, and is useful for quick local 'edit-compile-debug' loop (for example preliminary unit testing). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the technique that all the tests in the repo use -> This technique is used by all tests in the repo
also which repo? CoreCLR? I suggest naming it and linking to it
(for example preliminary unit testing) -> such as, preliminary unit testing
docs/core/building/index.md
Outdated
|
||
The source code for the .NET Core CLI can be found in [the `dotnet/cli` repository on GitHub](https://github.com/dotnet/cli/). | ||
|
||
In order to build .NET CLI, you need the following installed on you machine. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.NET CLI -> the .NET CLI
your machine
docs/core/building/index.md
Outdated
|
||
### Using your build | ||
|
||
Use the `dotnet` executable from *artifacts/{os}-{arch}/stage2* to try out the newly built CLI. You can also add *artifacts/{os}-{arch}/stage2* to the PATH if you want to use the build output when invoking `dotnet` from the current console. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mention if first in the second sentence?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand that one.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's about moving the "if" clause before the "then" clause :)
"You can also add artifacts/{os}-{arch}/stage2 to the PATH if you want to use the build output when invoking dotnet
from the current console."
->
"If you want to use the build output when invoking dotnet
from the current console, you can add artifacts/{os}-{arch}/stage2 to PATH"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes, that makes sense. Thanks Omair!
docs/toc.md
Outdated
@@ -77,6 +77,8 @@ | |||
### [Analyzing third-party dependencies](core/porting/third-party-deps.md) | |||
### [Porting libraries](core/porting/libraries.md) | |||
<!--### [🔧 NuGet packages](core/porting/nuget-packages.md)--> | |||
## [Building .NET Core](core/building/index.md) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Building -> Build
would it help to clarify what you're building? Build .NET Core from source, for example.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
closing and re-opening to force a new CI build. |
VSTS builds keep failing on this one which is odd since this doesn't touch code samples. I've also noticed the folder name still has ing, so I'll make this change and see what else was missed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've renamed the folder now. Pending a good build, this is good to go.
Build .NET Core from source
Summary
Instructions for building .NET Core from source, and for packaging and shipping it.
Details
The main topic reproduces a summary of build instructions from the relevant repos (CLR and CLI). This will eventually be replaced with a new set of instructions.
Another topic gives specific guidance for package maintainers about versioning and packaging .NET Core (addresses #1912).
Suggested Reviewers
@mairaw, @ellismg