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

Shim llvm::sys::getDefaultTargetTriple() to Swift #572

Closed
wants to merge 1 commit into from

Conversation

@brentdax
Copy link

commented Oct 3, 2019

The default target triple for the host machine can be useful information when constructing command line arguments for a tool, but this information isn’t in LLVM’s C API, so it’s inaccessible from Swift. This commit exposes it in libllbuild as llb_get_default_target_triple() and in llbuildSwift as BuildSystem.defaultTargetTriple.

The default target triple for the host machine can be useful information when constructing command line arguments for a tool, but this information isn’t in LLVM’s C API, so it’s inaccessible from Swift. This commit exposes it in libllbuild as `llb_get_default_target_triple()` and in llbuildSwift as `BuildSystem.defaultTargetTriple`.
@brentdax brentdax requested a review from aciidb0mb3r Oct 3, 2019
@brentdax brentdax requested review from ddunbar and dmbryson as code owners Oct 3, 2019
@brentdax

This comment has been minimized.

Copy link
Author

commented Oct 3, 2019

@swift-ci please smoke test


const char * llb_get_default_target_triple() {
// Use a static local to store the triple, to avoid lifetime issues.
static std::string tripleString = llvm::sys::getDefaultTargetTriple();

This comment has been minimized.

Copy link
@aciidb0mb3r

aciidb0mb3r Oct 3, 2019

Member

does this really work? LLVM goes to some extreme lengths to determine the default triple. I am not sure if llbuild does that as well.

This comment has been minimized.

Copy link
@brentdax

brentdax Oct 3, 2019

Author

I'm not quite sure what you mean. This ends up using the exact same code that would be called in the clang or Swift drivers. That code does sometimes invoke external tools or perform other heroics to determine the OS version, but all of that code looks like it's intended to be idempotent, so caching the result ought not to cause any problems.

This comment has been minimized.

Copy link
@aciidb0mb3r

aciidb0mb3r Oct 3, 2019

Member

I meant if the copy in llbuild actually does the heroics done by llvm. I checked and it seems like this is filled in at compile time using LLVM_DEFAULT_TARGET_TRIPLE defined to empty string in llbuild: https://github.com/apple/swift-llbuild/blob/master/include/llvm/Config/config.h#L356

This comment has been minimized.

Copy link
@brentdax

brentdax Oct 3, 2019

Author

Damn, you're right. Is there a particular reason we do this, or is it just because we haven't wanted this until now?

@brentdax

This comment has been minimized.

Copy link
Author

commented Oct 3, 2019

Looks like this won't work without a larger change to the way we configure llbuild.

@brentdax brentdax closed this Oct 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.