- 
                Notifications
    
You must be signed in to change notification settings  - Fork 1.4k
 
          Use -print-target-info instead of a hardcoded triple
          #2883
        
          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
  
    Use -print-target-info instead of a hardcoded triple
  
  #2883
              Conversation
| 
           @swift-ci please smoke test  | 
    
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we should do this, because we lose the deployment target consistency. That means if I'm running on macOS 11 and you're running on macOS 10.15, you might fail to compile the manifest.
Can we instead just read the default target from the compiler and swap the version for 10.15, and then use that?
| 
           @jakepetroules - Im not sure I understand what you mean by the deployment target consistency? The compiler will default to the build system which is where the manifest is going to be executed. The minimum deployment target will implicitly match the target system here.  | 
    
| 
           Oh you mean because I could be using APIs which aren't available on an older OS? I guess that's a good point.  | 
    
          
 That's right. Deployment target is something intrinsic to the code being compiled, not something that can be determined automatically.  | 
    
| 
           Yep, I wasn't really thinking about the fact that developers can use arbitrary APIs in the manifest.  | 
    
| 
           Is there a way to keep the deployment target as it is without also having to specify the architecture (leaving it to the compiler to select the host, so SwiftPM doesn't need to reimplement that logic)? At some point one might want to build for a different architecture than what the host supports, but for the moment, it seems better to specify the deployment target and leave out the architecture.  | 
    
| 
           Yah, that would be nice, but I don't think there's a way to do so. Open for any suggestions. Right now I'm planning to update this to essentially use   | 
    
1caf966    to
    9fd1884      
    Compare
  
    | 
           @swift-ci please smoke test  | 
    
-target flag from manifest loading-print-target-info instead of a hardcoded triple
      9fd1884    to
    fbf1b04      
    Compare
  
    | 
           @swift-ci please smoke test  | 
    
fbf1b04    to
    ee97d75      
    Compare
  
    | 
           @swift-ci please smoke test  | 
    
          
 Looks like something is going wrong in the bootstrapped SwiftPM, we're probably constructing the wrong   | 
    
ee97d75    to
    9c8b37c      
    Compare
  
    | 
           Ah yes, the triple string was constructed completely wrong 🤦♂️  | 
    
| 
           @swift-ci please smoke test  | 
    
| 
           Linux failure doesn't look related:  | 
    
| 
           @swift-ci please smoke test linux  | 
    
This has been present since the initial commit of SwiftPM and may have been needed back then, but isn't necessary anymore today. This brings the added bonus of compiling the manifest for the host architecture instead of a hardcoded x86_64.