-
Notifications
You must be signed in to change notification settings - Fork 0
Design Goals
The last several years have seen a number of .NET task runners being developed. Some of the most well known are Cake, Fake, and PSake. Although they are all generic task runners, they are all geared towards performing build-related tasks; and they all provide certain advantages over MSBuild, which has been the standard "task runner" / build tool for .NET since its release in 2005. So if these other tools already exist, why do we need another one?
The primary goal of Casper that sets it apart from other tools is efficiency at scale. Developers working on large code bases still need to be able to work quickly. Casper enables this efficiency by doing as little work as possible to achieve the goals of the developer. There are two primary aspects to this:
- Giving the developer the ability to specify at a very granular level exactly what needs to be done (see Features: Project-Aware)
- Recognizing when work that has already been done does not need to be done again (see Features: Incremental Build)
It is very common for build scripts to evolve over time from very simple to very complex. Often, very simple build scripts can be written in a declarative way using a DSL, which makes them more readable. However, inevitably as a project and its build system grow, there will be a need for functionality that does not fit will within existing declarations. At this point, it is important that the build system be able to express the new functionality in an imperative way, without losing the declarative nature of the existing logic.
For this reason, the primary scripting language for Casper is Boo (see Features: Scripting Language). Boo has syntactic features that lend themselves towards making the declarative-to-imperative transition, as well as a programmable compilation pipeline that and other features that make it good for writing DSLs.
All of the existing build tools for .NET ultimately delegate the responsibility for the actual compilation to MSBuild. This means that they are still dependent on the MSBuild tool chain (including *proj files), and it also means that the build script is essentially divided into the MSBuild and non-MSBuild components. This is undesirable for many reasons.
Casper will ultimately not delegate to MSBuild for compilation (or any other build tasks; see Features: Direct Compilation). This is a significant undertaking, given that so much of the .NET tooling is bound up in MSBuild. But the benefits justify the effort.