Implement fileAffectsSwiftOrClangBuildSettings with the logic from LLBuildManifestBuilder
#7699
Conversation
ahoppen
requested review from
bnbarham,
MaxDesiatov,
jakepetroules,
francescomikulis and
xedin
as code owners
|
@swift-ci Please test |
ahoppen
force-pushed
the
file-affects-build-settings
branch
2 times, most recently
from
49dfe0d to
26b8e0b
Compare
|
@swift-ci test |
|
@swift-ci test windows |
|
@swift-ci Please test |
| @@ -654,6 +662,34 @@ public class BuildPlan: SPMBuildCore.BuildPlan { | |||
| } | |||
| return try description.symbolGraphExtractArguments() | |||
| } | |||
|
|
|||
| /// Returns the files and directories that affect the build process of this build plan. | |||
| package var inputs: [Input] { | |||
There was a problem hiding this comment.
I'm not sure whether this is relevant but - traits are currently not considered by package structure command, is it possible for them to affect what files are included in the build and subsequently influence fileAffectsSwiftOrClangBuildSettings?
There was a problem hiding this comment.
Traits aren't affecting what files are included in a single module. The same files will be part of the module just different SWIFT_ACTIVE_COMPILATION_CONDITIONS are passed. Traits do effect build planning though. The swift build/run/test commands support trait configuration arguments to change the traits of the root manifests. If the root trait changes we have to re-plan the build. This is already implemented and the trait configuration is stored in the build description.
What are the package structure commands in question here?
There was a problem hiding this comment.
PackageStructure command determines whether anything changed in the package and would skip loading of modules graph, and rebuilding of the build plan if nothing changed if traits are not part of that consideration there is a possibility of a split-brain scenario if something started directly using buildPackageStructure() result as an indicator for a rebuild.
…`LLBuildManifestBuilder` Instead of inspecting file extensions to decide whether a file might affect build settings, check which files are in directories that are affecting compilation. This is the same logic that `LLBuildManifestBuilder` uses and should be more stable. In particular, this stops us from reloading the package manifest in SourceKit-LSP when a header file is written to a `.build` directory. rdar://128573306
ahoppen
force-pushed
the
file-affects-build-settings
branch
from
26b8e0b to
99d92ca
Compare
|
@swift-ci Please test |
|
@swift-ci test windows |
… from `LLBuildManifestBuilder` (#7709) - **Explanation**: Instead of inspecting file extensions to decide whether a file might affect build settings, check which files are in directories that are affecting compilation. This is the same logic that `LLBuildManifestBuilder` uses and should be more stable. In particular, this stops us from reloading the package manifest in SourceKit-LSP when a header file is written to a `.build` directory. - **Scope**: Only affects SourceKit-LSP - **Risk**: Low, only affects SourceKit-LSP - **Testing**: Adding a SourceKit-LSP test case in swiftlang/sourcekit-lsp#1512 - **Issue**: rdar://128573306 - **Reviewer**: @MaxDesiatov @xedin on #7699
Instead of inspecting file extensions to decide whether a file might affect build settings, check which files are in directories that are affecting compilation. This is the same logic that
LLBuildManifestBuilderuses and should be more stable. In particular, this stops us from reloading the package manifest in SourceKit-LSP when a header file is written to a.builddirectory.rdar://128573306