Behind the Build — .2585

Welcome back to Behind the Build, where we take a  look at some of the new changes and improvements in the latest Elements build.

Build .2585 marks the 59th (!) and last Elements release of 2020, so let's see what's going on.

.NET 4.8

The compiler and entire toolchain as been moved up to run on (read: require) .NET 4.8. On Windows, the new version of the framework will automatically installed for you as part of setup, if required.

The move to .NET 4.8 was made necessary because we wanted to switch Cirrus, our AOP library, to .NET Standard, so that the same aspect libraries can now (safely) be used from . NET, .NET Standard and .NET Core projects (and of course all other non-.NET platforms). Cirrus needs .NET Standard 2.0, and urns out the old target framework for the compiler, 4.5, did not support that.

Note that you can still compile for any .NET version from 2.0 to 5.0 (and beyond); just the compiler runs on 4.8 now. Since .NET 4.8 is  going to be the last non-.NET Core version Microsoft will ever ship, and there are several good reasons why we cannot switch fully to .NET Core anytime soon, the change to .NET 4.8 will last us a while.

Improved support for developing on Windows/ARM.

This week, Parallels shipped the first preview of their VM tool for Apple Silicon, with the ability to run Windows/ARM on M1 Macs. I've been long waiting to try out Windows/ARM and what parts of Elements work and don't work on it, so here was my chance!

It turns out, Elements and Water install and run fine. Of course, they are based on .NET 4.8 and that does nut support ARM natively yet, but runs emulated. But its very speedy and Water runs fine, fast and super-usable as 32-bit Intel (and, in the latest Windows Insider build, 64-bit Intel). Now keep in mind, .NET, JITted to Intel, emulated on arm64, running in a VM on a Mac. And it's fast. WOW.

A few fixes were needed to the tool chain to make some ARM specific things work, such as detecting a .NET Core install. But with those out fo the way, Water is usable for general Elements development on Windows/ARM, for .NET, .NET Core, WebAssembly, Cocoa, and (Intel) Island. I haven't tested Android yet, and of course our Islands back-end does nit support native Windows/ARM yet (but that's bumped up higher on the list for early next year).

New caseInsensitive() API

This is a small but nifty API that we added in Elements RTL to alleviate a small annoyance I had in the codebase for EBuild. EBuild has a single place that defines the canonical default value for every single project setting — it defines what the compiler sees, what the IDEs show, etc, if a setting is not set, to make sure there are no magic "default" behaviors for undefined settings all thru-out the compiler. Each setting will always get a value.

As you can imagine, this default provider is a set of huge "case" (or "switch", for the non-Oxygene folks) statements that handle any possible known settings. Now, case  statements for strings (a feature unique to/pioneered by Elements, BTW — neither Delphi or Visual C# support that) are of course case sensitive, so what i had to do in the past was call ToLowerInvariant() on the value, and have all the setting names lowercased as string literals. Annoying and error-prone, as literals didn't match the canonical case of the setting names.

No more. Now, this code will compile and work — the correct case statement will be matched

var x := "OUTputTyPE";

...

case caseInsensitive(x) of
  "OutputType": result := "Executable";
  ...

The cool thing is, originally I ran this by the compiler team as an idea for a compiler feature, but it turned out I could solve it purely in code, and with fewer than 50 lines as well. Check out the neat trick here on GitHub.

And, always, more

As always, thats just a few of the new things this week. There's many improvements to Mercury, including ported templates for creating macOS apps and support for Option Strict Off. There's toolchain improvements for .NET Core, and the start for toolchain support for Xamarin frameworks (focus on References and Compilation, for now). Ands Water now detects and can use Microsoft Edge for WebAssembly debugging, if Chrome or Brave aren't installed. Nice, because.

See the full change log here.