Symlink swift and swiftc to swift-driver, when available #69834
Conversation
| @swift-ci test |
artemcm force-pushed the DefaultNewDriverSymlink branch from dea64f9 to 53b2111 Compare artemcm force-pushed the DefaultNewDriverSymlink branch 2 times, most recently from 44d473c to ec7934c Compare artemcm changed the title swift and swiftc to swift-driver, when available 
tools/driver/CMakeLists.txt Outdated
There was a problem hiding this comment.
As far as I can tell what happened here is that #6053 added this and removed the others, but that was somehow lost in the conflict resolution in #10337. I haven't looked at the LLVM closely, but I assume we should probably prefer add_swift_tool_symlink over swift_create_post_build_symlink and swift_install_in_component? Any thoughts @edymtt/@compnerd?
There was a problem hiding this comment.
One thing about add_swift_tool_symlink is that it requires the "source" be a component. So we can't simply call:
add_swift_tool_symlink(swift swift-driver compiler) Because that leads to:
CMake Error at /Volumes/Data/GHWorkspace/build/Ninja-Release/llvm-macosx-arm64/lib/cmake/llvm/AddLLVM.cmake:2168 (get_target_property): get_target_property() called with non-existent target "swift-driver". 
There was a problem hiding this comment.
@bnbarham yes, we do prefer the add_swift_tool_symlink because it correctly handles the install of the link (or in the case of Windows, copy 😠). This makes it significantly better for building the toolchain distribution. Without that we will need to add a whole slew of custom install logic.
There was a problem hiding this comment.
To be clear, we have that logic already (we have both today):
swift_install_in_component(FILES "${SWIFT_RUNTIME_OUTPUT_INTDIR}/swift${CMAKE_EXECUTABLE_SUFFIX}" DESTINATION "bin" COMPONENT compiler) One thing about add_swift_tool_symlink is that it requires the "source" be a component. So we can't simply call:
We could fix that by adding a custom target for the early swift driver (which does the copy) right? ie. change swift_create_early_driver_copies to instead use add_custom_command + add_custom_target rather than configure_file.
There was a problem hiding this comment.
We already have a slew of custom install logic though, with swift_install_in_component later in this file.
We can pursue a refactor here to replace both swift_create_post_build_symlink and swift_install_in_component with LLVM tooling, but as-is, the logic is already there, and add_swift_tool_symlink would not work for this use-case for the reason described above.
There was a problem hiding this comment.
Also, swift_install_in_component does, I believe, already do Windows-specific things (copy instead of symlink) so I don't think this will functionally change much here.
artemcm force-pushed the DefaultNewDriverSymlink branch from ec7934c to e613b4b Compare artemcm force-pushed the DefaultNewDriverSymlink branch from e613b4b to f380790 Compare 1 similar comment
artemcm force-pushed the DefaultNewDriverSymlink branch 2 times, most recently from 16b9012 to b89b5d7 Compare | swiftlang/swift-driver#1485 |
artemcm force-pushed the DefaultNewDriverSymlink branch from b89b5d7 to f935713 Compare 
| @swift-ci please build toolchain Windows platform |
| swiftlang/swift-driver#1485 |
3 similar comments
| swiftlang/swift-driver#1485 |
| swiftlang/swift-driver#1485 |
| swiftlang/swift-driver#1485 |
… of the driver CMake target
…e 'compiler' component
… invoked from 'swift-driver')
artemcm force-pushed the DefaultNewDriverSymlink branch from f935713 to 6a181fb Compare | @swift-ci please build Windows toolchain |
| @swift-ci please build toolchain Windows |
1 similar comment
| @swift-ci please build toolchain Windows |
3 participants
add_swift_tool_symlinkon/binexecutables of the driver CMake targetswiftandswiftctoswift-driver, when available (whenearlyswiftdriverwas built with the host toolchain (default))swift-driverandswift-helpwhen installing the 'compiler' componentswift-driver)swift-driverchange: Add fallback to auxiliary legacy driver executable on '--disallow-use-new-driver' swift-driver#1485