Skip to content

Conversation

@bkhouri
Copy link
Contributor

@bkhouri bkhouri commented Nov 12, 2025

The triple name in the SwiftBuild build system is redundant. Remove the triple from the output path.

@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 12, 2025

@swift-ci test

// can be used to build for any Apple platform and it has its own
// conventions for build subpaths based on platforms.
return "apple"
case .swiftbuild, .native:
Copy link
Contributor

Choose a reason for hiding this comment

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

While the new and old build systems coexist I wonder if we should include "swift-build" here to separate build products for users switching between the two. Not sure I have a strong opinion here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

All build systems can co-exists together today.

Xcode has: .build/apple/Products/<configuration>
Swift Build has: .build/Products/<configuration>
native has: .build/<triple>/<configuration>

Copy link
Member

Choose a reason for hiding this comment

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

There are other things in the scratch path than build output. We may add more over time. I'm with Owen, we should have a directory for the build system. I would use the build system name "swiftbuild". Save us a character with the path length issues we've had. :)

Copy link
Contributor

Choose a reason for hiding this comment

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

"Products" also isn't accurate because this directory contains more than just products (also intermediates and build system bookkeeping state).

I wouldn't use "swiftbuild", it just feels weird to have the component name as part of the path. Maybe just "out"?

Copy link
Member

Choose a reason for hiding this comment

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

I also thought of just "build".

Copy link
Contributor

Choose a reason for hiding this comment

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

.build/build is a little strange looking though

Copy link
Member

Choose a reason for hiding this comment

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

You can always change the scratch-path to be not .build if it bugs you :)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

it would be a bigger impact changing the default scratch path directory.

From a SwiftPM perspective, the Products and Intermediates are siblings. Here's a sample where SwiftPM puts the SwiftBuild output in a <scratchPath>/out directory.

❯ ls .foo/out 
CompilationCache.noindex Intermediates.noindex    ModuleCache.noindex      Products                 SDKStatCaches.noindex

❯ ls .foo/out/Products 
Debug

Copy link
Member

Choose a reason for hiding this comment

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

I mean the user can change it. I'm just trying to make sure people are thinking about the scratch path as a directory SwiftPM can put any scratch files into, not just build output. And that it's not always named .build.

Copy link
Contributor Author

@bkhouri bkhouri Nov 17, 2025

Choose a reason for hiding this comment

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

I guess we can rename the default scratch path directory as we have subcommands that deal with cleaning the build output (swift package clean) and all files produced by SwiftPM (swift package reset).

Developers should be using swift package reset instead of rm -rf <scratch-path-directory>.

@bkhouri bkhouri force-pushed the t/main/remove_triple_from_build_output branch from dbcef71 to 9208a2d Compare November 12, 2025 23:14
@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 12, 2025

@swift-ci test

@bkhouri bkhouri force-pushed the t/main/remove_triple_from_build_output branch from 9208a2d to 7f8e26b Compare November 15, 2025 19:55
@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 15, 2025

@swift-ci test

@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 15, 2025

@swift-ci test windows

@bkhouri bkhouri force-pushed the t/main/remove_triple_from_build_output branch from 7f8e26b to c1e869e Compare November 16, 2025 03:54
@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 16, 2025

@swift-ci test

@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 16, 2025

@swift-ci test windows

The triple name in the SwiftBuild build system is redundant.  Remove the
triple from the output path.
@bkhouri bkhouri force-pushed the t/main/remove_triple_from_build_output branch from c1e869e to 85d5e13 Compare November 16, 2025 06:10
@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 16, 2025

@swift-ci test

@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 16, 2025

@swift-ci test windows

@bkhouri bkhouri enabled auto-merge (squash) November 16, 2025 06:12
// can be used to build for any Apple platform and it has its own
// conventions for build subpaths based on platforms.
return "apple"
case .swiftbuild, .native:
Copy link
Member

Choose a reason for hiding this comment

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

I mean the user can change it. I'm just trying to make sure people are thinking about the scratch path as a directory SwiftPM can put any scratch files into, not just build output. And that it's not always named .build.

@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 17, 2025

@swift-ci test windows

1 similar comment
@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 17, 2025

@swift-ci test windows

@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 20, 2025

@swift-ci test

@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 24, 2025

@swift-ci test self hosted windows

@bkhouri
Copy link
Contributor Author

bkhouri commented Nov 27, 2025

@swift-ci please test self hosted windows

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.

4 participants