[SR-3583] Segregate build products by platform

[aciidgh]

Previous ID	SR-3583
Radar	None
Original Reporter	@aciidb0mb3r
Type	Improvement
Status	Resolved
Resolution	Done

Additional Detail from JIRA

Votes	1
Component/s	Package Manager
Labels	Improvement
Assignee	@hartbit
Priority	Medium

md5: 47319df353de59752ec79b55137e29ac

is duplicated by:

• SR-4898 SPM crashes when rebuilding project

Issue Description:

This is useful so the build directory can be shared between Host and a VM without over writing the data.

[keith]

Is this ticket suppose to be about creating the symlink to the old build location?

[hartbit]

No, this ticket is about the whole platform specific folder feature. The symlink is part of it.

[weissi]

@hartbit sorry to just chime in without taking part in the design discussions. Just wanted to check that we have a story for cross-compilation. I'm guessing that cross compiled binaries for a given target would go in the same folder as a natively compiled binary for that target. Does that make sense?

We cross-compile Linux binaries on macOS and then run them in Docker. So if I were then to trigger a rebuilt within Docker, it'd re-use that same build folder and potentially update certain build products, right?

Maybe we should start thinking about an end-to-end testing story for SwiftPM, do you know if there's anything in place?

[ddunbar]

@weissi yes, I expect the cross compiled binary for "foo" should go in the same place it would go if built on "foo" natively. Hopefully we can eventually get to a place where they even build the exact same bits.

This probably won't work out-of-the-box if we share the build folder given how llbuild invalidates the build graph, but I think it should be the goal. `swift run --skip-build ...` will work to run the product without rebuilding in the meantime.

What did you have in mind for end-to-end testing? We do some limited testing on the final packages produced for our snapshots, but we don't use it very much because it doesn't cycle frequently enough to be a good place to develop tests, unfortunately.

[weissi]

@ddunbar sounds good! I thought maybe making up a fake toolchain where swiftc/clang/... are just shell scripts that validate certain expectations (correct target, contains certain special marker compiler flags, ...) about their invocations and write more or less empty dummy files. And then we could create a destination.json which targets the fake toolchain with some marker compiler flags and we'd be sure that they get handed through.

[ddunbar]

@weissi oh, yes that's something we could just fit directly into the tests themselves, we already have many tests which essentially run `swift-build`.