On Friday we published Elements build .2605, the first "Stable" channel build of the year, and wrapping together a lot of great changes and improvements from the past couple months of previews.
Let's have a look at some of the new features and enhancements
Support for Importing .xcframeworks
.xcframeworks are a new(ish) file format introduced by Xcode that allows grouping a set of frameworks for two or more Apple platforms in one container. Essentially, it is a folder structure that can contains separate regular .frameworks, build for each of Apple's SDK types (macOS, iOS, tvOS, watchOS) and (in EBuild parlance) Build Destinations (Device, Simulator, Mac Catalyst).
For a while, Elements has been able to automatically import Objective-C .frameworks for use in your projects, via Import Projects, and Fire (and theoretically, Water — but be careful there, as .frameworks tend to break when copied to a Windows file system) can create such Import Projects for you, when you simply drag the .framework into your solution, or as a Reference into a Cocoa project.
The same now works for .xcframeworks. Just drag them in, and Fire will create a multi-target Import Project for you, with targets for each SDK that the .xcframework supports, and for both Toffee and Island backends. When the Import Project gets built, EBuild will automatically pick the right .framework form inside the .xcframework folder structure for each target and build destination.
Code-behind Generators
On the .NET platform, generators are used to create .Designer.x files for Settings, Resources and — in Mercury — .myapp files. In the past, these generated .Designer files lived as part of the project, and had to manually updated when the file that drove their content changed. This is no longer the case.
You can now optionally delete the .Designer.pas (.Designer.cs, etc) file form your project, and if you do, EBuild will automatically generate it from the .settings, .resx or .myapp file at build time and inject the result into the compile.
On less source file to worry about, and you can be assured the .Designer code will always be up to date.
Our .NET project templates have all been updated to reflect this new model, but your existing projects will not be affected, unless you explicitly opt in by deleting (or simply removing) the .Designer.x code file from your project.
Optional Locking
A very small change, but the Oxygene locking statement (and its equivalents in the other languages now accepts nil as a lock object, and not cause a lock in that case. This makes it very easy to write code that can optionally lock when a lock object is assigned, or not, if it is not.
Background: the use case we added this for was EBuild itself. A while ago, we added support for parallel builds in EBuild — the option to build several projects, or sub-tasks of projects, in parallel , if their dependencies allow it (you can enable this in the IDE, or with the --parallel command line option). This required the addition of locks in a few places for thread safety, obviously, but on the flip side, these locks are just unnecessary overhead when running in (normal) non-parallel mode.
This new compiler change made it very easy to only use the locks when running in parallel mode — without having to encode that decision in every single place the lock is required. EBuild simple assigns or clears its global lock object, depending on whether locking is needed.
Uppercase Oxygene Keywords
For those crazy ones among you who like their Oxygene code to YELL AT YOU, Fire and Water now expose an option to make it easier to have your keywords in uppercase. Simply switch the "Use upper-case Oxygene Keywords" option in Editor preferences,, and the editor will automatically uppercase keywords as you type them (similar to how it automatically PascalCases Mercury keywords), and use uppercase for keyword completion (such as "if<space>" adding "then").
And so much more...
And as always, this is just the mere tip of the Eisberg. Check out the full weekly build logs for for the complete list of changes.
