Standardize scripts across console and extension repos

[CharliePoole]

The extension projects and the engine/console project are closely related. It will be more convenient for developers if they can be standardized so that...

• They support the same targets and options to the extent possible
• Targets with the same names do the same thing and have the same dependencies
• The structure and naming of cake files is the same

If the above can be achieved, it will be possible to create a common recipe as a separate repo, but that's not absolutely needed for ease of use and isn't part of this particular issue.

[CharliePoole]

Scope

This is a mini-project covering the scripts the console runner and those extensions maintained by the NUnit team:

• Standardize scripts across console and extension repos #1422 (this issue)
• Standardize scripts across console and extension repos nunit-project-loader#67
• Standardize scripts across console and extension repos vs-project-loader#66
• Standardize scripts across console and extension repos nunit-v2-result-writer#36
• Standardize scripts across console and extension repos nunit-v2-framework-driver#52

Since the extensions to be supported in version 4 are unknown, I'll concentrate on version 3 until there is more info.

Approach

1. Working with nunit-console and nunit-project loader in parallel, bring them to a level of parity. All common code will be kept separate from code that is unique to a particular project. Ideally, both projects should end up with the same content in the cake subfolder, but if that's not possible, any differences should be localized to articular files.

2. Iteratively add additional extension projects to the mix, bringing all of them to the same level of parity.

3. It's likely that the extensions will need some common code, which is not needed by the runner. In particular, the extensions are tested against multiple release versions of the runner. Such code will also be isolated in a separate file or files.

[CharliePoole]

I have marked this as temporarily blocking other work because I don't want to create further PRs until PR #1426 is merged. It's too awkward to work with entirely different build scripts in different branches. Once #1426 merges, further changes will be incremental. Issues currently blocked by this are #1427 and #1428

[veleek]

This looks like a perfectly reasonable approach to me!

For 1. by parity here are you talking about parity with the existing scripts, or just keeping them roughly together in parity with each other?

For 2. Can you add some detail about what's covered by "add additional extension projects to the mix"? Which projects is that exactly (for those of us not too familiar with stuff)? Is "vs-project-loader" considered an extension?

[CharliePoole]

@veleek Good questions, which may help others as well.

Parity... at a minimum if you run the build script with specific named targets and options, they should do the same thing in each project. Ideally, the same targets and options should be available in each project unless they don't make sense for that project.

Going a step further, I'd like to centralize the scripts in some way so that they don't have to be maintained centrally, but that's not for this issue. I'd just like to get something to serve as a starting point.

Extensions means NUnit engine extensions: dynamically loaded assemblies that add functionality of a specific type to the engine. The vs project loader is a great example. Anyone can write extensions. The NUnit team maintaiins four extensions: vs project loader, nunit-project-loader, v2 format result writer, v2 framework driver.

As an overall plan, I want to get it working for the console, copy it to the nunit project loader, modify it so both have the same code and then create a common script that both use. Finally, I'll extend that script to the other three. That would probably be overly ambitious, except that it's the second time I've done it - testcentric has about 20 projects all using the same scripts. I've pulled a lot of parts out of those scripts and adapted them to nunit, which has different priorities and standards.

Long answer I know. :-)