SE-0387: Cross-Compilation Destination Bundles

Evolution Proposal Reviews
6

Love that this is being considered and seems good overall, but I have some questions and notes, after going over the proposal in detail:

  • You should have an example for the destination JSON, so that we know exactly how it will be used.
  • What is the use of buildTimeTriples, which didn't exist in the previous JSON format? Since SPM queries the compiler to figure out the host triple and the bundle already places each destination JSON in a host variant triple directory, this array of buildtime triples seems superfluous.
  • Is the idea that the length of the runTimeTriples array will match the length of the swiftResourcesPaths array, with the first of each corresponding and so on? If so, would the same be done with include and library search paths? Since you might want to provide multiple include or library paths per runtime triple, you may want to specify that one could also pass in an array of include/library paths per runtime triple, ie include/librarySearchPaths could be an array of arrays.
  • Having an array of runtime triples is so one destination can cross-compile for multiple arches, but you are then going to run into the issue that the Swift resource directory doesn't support multiple arches for platforms that don't have "fat" multi-arch libraries. That means you'll have to duplicate the non-platform-specific directories in a resource directory, that mostly have C headers and some clang libraries, which currently account for 20+ MB out of a 270 MB resource directory that comes with the current linux x86_64 toolchain, for example. If we ever fix that, so that all the arches can be installed in a single Swift resource directory, then we'll have the same resource directory path listed multiple times in the swiftResourcesPaths array. I'm not sure you can do anything about this issue right now, but it is worth thinking about.
  • I'm skeptical of all the toolset combinations posited, which presumably comes from CMake experience of the authors. Maybe that can be motivated more.
  • I like that the toolset allows explicitly specifying some of the tools used, but why stop with those four tools? SPM currently looks for a lot more, like a librarian archiver for static libraries and lldb.
  • Speaking of tools, many of those are currently looked for in the toolchain and if not found, taken from the system PATH. That is going to break cross-compilation in all kinds of subtle ways because it may end up inadvertently depending on random tools in the user's PATH. Instead, we should audit all the tools that SPM calls and make sure cross-compilation is only done by the tools in the bundle or explicitly specified in a toolset, ie disable looking in the system path when using these bundles.
  • The first future direction mentions hostTriple and destinationTriple, which are no longer part of the latest proposal and should be updated.
  • Another possible future direction would be to have bundle registries, similar to the current package registries.
  • Thought of one more, the proposal should explicitly specify how the triple is chosen when a destination supports multiple runtime triples, ie write out an example of that command.
3 Likes