eatdrinksleepcode / casper Goto Github PK

What needs to be done to:

• Build on .NET Core
• Run on .NET Core

https://docs.microsoft.com/en-us/visualstudio/msbuild/how-to-use-project-sdk

Show output if the task fails?

Tasks with the same name in different imported projects are currently resolved via "first in wins", which is not intuitive. Instead, require specifying the full "path" to the task (i.e. the delimited list of project names) for all tasks.

Currently, task configuration is typically done via constructors, using Boo's version of object initializers:

task Pack(Exec,
  Executable: 'nuget.exe')

This essentially requires all task configuration to be done within a single expression which can get unwieldy. It would be great if we could do task configuration within a closure, which would allow each configuration entry to be its own statement:

task Pack(Exec):
  Executable = 'nuget.exe'

However, because Boo does not have the concept of function "receivers" (what Groovy would refer to as a "delegate"), the "Executable" identifier in this example cannot be resolved, resulting in a compiler error. An instance of the task would have to be passed in as a parameter, and code in the function would have to refer to the task explicitly:

task Pack(Exec):
  task.Executable = 'nuget.exe'

This is not much different - and arguably not even any better - than not even using a closure, but configuring the task directly:

task Pack(Exec)
Pack.Executable = 'nuget.exe'

But while this works and is highly flexible, it fails to create a natural structure in the build script, and is also quite redundant. Both of these factors hurt script readability.

One option to consider would be creating Boo macros for the major built-in tasks. A reference to the task parameter could then be injected automatically:

task Pack(Exec):
  executable 'nuget.exe'

While this comes very close to emulating our desired form, it requires a macro to be written for every property of every task, which is a lot to maintain. It would also be more to understand and more work for custom task authors. But IF we think that Boo will ultimately implement some form of receiver functions, this could be a temporary stepping stone to our desired end state.