Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-3583] Segregate build products by platform #5134

Closed
ankitspd opened this issue Jan 9, 2017 · 6 comments
Closed

[SR-3583] Segregate build products by platform #5134

ankitspd opened this issue Jan 9, 2017 · 6 comments
Assignees

Comments

@ankitspd
Copy link
Member

ankitspd commented Jan 9, 2017

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
Copy link
Collaborator

keith commented Jun 19, 2017

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

@hartbit
Copy link
Collaborator

hartbit commented Jun 19, 2017

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

@weissi
Copy link
Member

weissi commented Jun 20, 2017

@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
Copy link
Member

ddunbar commented Jun 20, 2017

@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
Copy link
Member

weissi commented Jun 20, 2017

@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
Copy link
Member

ddunbar commented Jun 20, 2017

@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`.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
@shahmishal shahmishal transferred this issue from apple/swift May 4, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants