-tools-directory path is absolute in your configuration though, pointing to a directory within the Android NDK. Thus it isn't a non-escaping relative path within a destination bundle.
Yep.
Looks like we need to introduce a separate JSON property and a destination install option to override that.
Maybe it would be best to just have a way to edit or override specific properties of the destination JSON file that comes with a cross-compilation bundle, ie either let users edit the one they downloaded or add their own local JSON that overrides the properties they want from the bundle, eg to add absolute paths only they know?
That may prove more usable than trying to anticipate every extra clang/swiftc flag that requires an absolute path and adding all those into the JSON format as separate properties now.
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.
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.
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".
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.