You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
I've been seeing a bunch of emit-module.d files in my Swift package directories with the latest 5.7 and trunk snapshot builds. The first Apr. 12 5.7 snapshot doesn't have this problem, so building with swift build -v then comparing to the Apr. 18 snapshot shows that both run this identical command to emit a module:
which causes all those files to be dumped in the top level of the package, rather than in .build/ where they belong. I can reproduce with the Apr. 20 trunk snapshot and later for Ubuntu too. Adding -Xswiftc -disallow-use-new-driver works around the problem.
To Reproduce
Install a recent snapshot of the Swift toolchain.
Run swift build on any Swift package.
Check with ls *.emit-module.d.
Expected behavior
No build files dumped outside the .build directory.
Environment:
OS: Ubuntu 20.04 x86_64
Additional context #1056 most likely caused this problem.
The text was updated successfully, but these errors were encountered:
Describe the bug
I've been seeing a bunch of emit-module.d files in my Swift package directories with the latest 5.7 and trunk snapshot builds. The first Apr. 12 5.7 snapshot doesn't have this problem, so building with
swift build -v
then comparing to the Apr. 18 snapshot shows that both run this identical command to emit a module:but when translated to the
swift-frontend
only the later snapshot adds an unprefixed-emit-dependencies-path
:which causes all those files to be dumped in the top level of the package, rather than in
.build/
where they belong. I can reproduce with the Apr. 20 trunk snapshot and later for Ubuntu too. Adding-Xswiftc -disallow-use-new-driver
works around the problem.To Reproduce
swift build
on any Swift package.ls *.emit-module.d
.Expected behavior
No build files dumped outside the
.build
directory.Environment:
Additional context
#1056 most likely caused this problem.
The text was updated successfully, but these errors were encountered: