An overrides mechanism is what I'm prototyping right now. Want to see whether we can do it nicely as an overriding CLI option or we need a way to override the whole JSON altogether.
1 Like
An updated version of the pitch has been published, which I hope addresses most if not all of the recent feedback. I've updated nomenclature to use "build-time triple" and "run-time triple" instead of "host target" and "target platform", as we think that "target" is too ambiguous in the context of the pitch, especially as it already mentions SwiftPM binary targets multiple times.
Properties of destination.json file have been reworked to support arrays of paths, together with a new swiftResourcesPaths property.
Additionally, in this version we're introducing a concept of toolset files, which are somewhat inspired by CMake toolchain files. We also propose a new swift destination configure subcommand for providing toolsets, header search paths, and library search paths that may come outside of a destination bundles.
Many thanks to everyone providing feedback and suggestions for this pitch! Specifically, @etcwilde and @compnerd came up with ideas for specifying search paths as arrays and toolsets as separate files, and are now credited as co-authors.
3 Likes
This has moved to the proposal stage, here's a link to the review thread: SE-0387: Cross-Compilation Destination Bundles
2 Likes
I'm a bit late, but I have got to say that I find the new naming extremely confusing since the entire process of cross-compilation is happening at build-time, so either triple is technically a "build-time triple". In fact, the only things running (if we don't take into account testing which the proposal isn't covering) are on the host, so technically the triples used for choosing host tools would be more appropriately named "run-time triples".
2 Likes
I personally think "host"and "target" are still the clearest terminology, the "host' is where the build runs (eg localhost) and the "target" is the platform you are building for.
9 Likes