Skip to content

Use swift-frontend from the host for SupportedFeatures.json #34686

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

Closed
wants to merge 1 commit into from

Conversation

edymtt
Copy link
Contributor

@edymtt edymtt commented Nov 11, 2020

Addresses rdar://71282911

@edymtt
Copy link
Contributor Author

edymtt commented Nov 11, 2020

@swift-ci please build toolchain

@edymtt
Copy link
Contributor Author

edymtt commented Nov 11, 2020

@swift-ci please smoke test

@edymtt
Copy link
Contributor Author

edymtt commented Nov 11, 2020

Follow up of #34655

@compnerd
Copy link
Member

Hmm, Im not sure how this is supposed to work. There are two scenarios here:

  1. you are building the standard library only and you specify the SWIFT_NATIVE_SWIFT_TOOLS_PATH
  2. you are building the Swift toolchain for testing which will build the standard library. In such a case, SWIFT_NATIVE_SWIFT_TOOLS_PATH is not set, and swift-frontend should be used from SWIFT_RUNTIME_OUTPUT_INTDIR.

In fact, I would argue that the first case doesn't apply to this at all - the SupportedFeatures.json should be generated when generating the toolchain, so it should always be executed from the output directory. Even in the cross-compilation case, it should be the version of the toolchain that is being built that determines the features of the toolchain, not the host toolchain that may be used in the generation of the toolchain.

Perhaps the right thing to do here is to only generate it if the toolchain is not being cross-compiled, that is:
if(NOT CMAKE_CROSSCOMPILING).

@edymtt
Copy link
Contributor Author

edymtt commented Nov 11, 2020

SWIFT_NATIVE_SWIFT_TOOLS_PATH is used during the compilation of the macOS toolchain -- in particular when we are cross compiling we are setting that to the host toolchain we just built (see https://github.com/apple/swift/blob/main/utils/build-script-impl#L1791), which should be what we want.

This target seems only run if we are building bin/swift-frontend, so the change should not affect building only the standard library

@edymtt
Copy link
Contributor Author

edymtt commented Nov 11, 2020

@swift-ci please test Windows

@edymtt
Copy link
Contributor Author

edymtt commented Nov 11, 2020

@swift-ci please test stdlib with toolchain

@swift-ci
Copy link
Contributor

Build failed
Swift Test OS X Platform
Git Sha - 3055b68

@compnerd
Copy link
Member

This target seems only run if we are building bin/swift-frontend, so the change should not affect building only the standard library

Thats what I had assumed and hence why I had said

I would argue that the first case doesn't apply to this at all - the SupportedFeatures.json should be generated when generating the toolchain

This code path is specific to building the toolchain. But, I wanted to verify that the assumption was correct. It seems that it is.

SWIFT_NATIVE_SWIFT_TOOLS_PATH is used during the compilation of the macOS toolchain -- in particular when we are cross compiling we are setting that to the host toolchain we just built (see https://github.com/apple/swift/blob/main/utils/build-script-impl#L1791), which should be what we want.

This is where I think that the problem actually is.

Perhaps the right thing to do here is to only generate it if the toolchain is not being cross-compiled, that is:
if(NOT CMAKE_CROSSCOMPILING).

AIUI, the features are meant to be the features of the toolchain being built, not the features with which the toolchain was built. This means that we need to run the binary that is being generated. This requires that we are not cross-compiling. In the case that we are cross-compiling, we have no good way to ensure that the toolchain was built at the same revision and same configuration (configuration can impact the feature set in theory).

@edymtt
Copy link
Contributor Author

edymtt commented Nov 11, 2020

Sorry for not understanding your point in the first place -- I blindly based my fix on a similar issue (#33402) without realizing that in this case that the role of the executable invoked is more relevant.

@finagolfin
Copy link
Member

Just a note about this point,

you are building the Swift toolchain for testing which will build the standard library.
In such a case, SWIFT_NATIVE_SWIFT_TOOLS_PATH is not set

Even if SWIFT_NATIVE_SWIFT_TOOLS_PATH is not externally passed in by CMake, it is internally defined and used, so it has always been set to something and can be used for invocations like this. I don't know about features.json, so not saying anything about the overall pull.

@swift-ci
Copy link
Contributor

Linux Toolchain (Ubuntu 16.04)
Download Toolchain
Git Sha - 3055b68

Install command
tar zxf swift-PR-34686-494-ubuntu16.04.tar.gz
More info

Copy link
Contributor

@nkcsgexi nkcsgexi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This won't work because we intend to use the just-built compiler to emit this file.

@edymtt
Copy link
Contributor Author

edymtt commented Nov 11, 2020

Thanks everyone for the feedback!

Closing this for the sake of clarity.

@edymtt edymtt closed this Nov 11, 2020
@swift-ci
Copy link
Contributor

macOS Toolchain
Download Toolchain
Git Sha - 3055b68

Install command
tar -zxf swift-PR-34686-767-osx.tar.gz --directory ~/

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

Successfully merging this pull request may close these issues.

5 participants