Skip to content

Build host tools in release even when leaf target is building for debug #7233

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

Open
rauhul opened this issue Jan 5, 2024 · 5 comments
Open
Labels
enhancement performance Performance optimizations and improvements

Comments

@rauhul
Copy link
Member

rauhul commented Jan 5, 2024

Targets which depend on macros and plugins should use release variants of those tools even if the target itself is being built in debug mode.

An optional flag can be used to build the host tools in debug.

@rauhul rauhul added enhancement performance Performance optimizations and improvements labels Jan 5, 2024
@neonichu
Copy link
Contributor

neonichu commented Jan 5, 2024

Plugins don't follow the regular build at all and are currently always build in debug mode, but if we had an option to select the build configuration we could easily change that.

Things are more tricky for targets in the regular build graph because this implies that we need the ability to build multiple copies of targets, e.g. if you have a macro and are building a product that uses swift-syntax in debug mode in the same build graph.

@rauhul
Copy link
Member Author

rauhul commented Jan 9, 2024

Definitely introduces complexity to spm but I think it's both warranted and necessary. In medium to large use of swift-mmio, I see the emit-module time drop from ~2.5m to ~20s after switching from debug to release.

@MaxDesiatov MaxDesiatov self-assigned this Jan 18, 2024
@MaxDesiatov MaxDesiatov removed their assignment Sep 18, 2024
@dfed
Copy link
Contributor

dfed commented Feb 26, 2025

Any movement here? In my own project that uses plugins I've built some gnarly hax to download and install a release binary for adoptees so the build plugin runs in reasonable time.

This isn't something I expect most developers will devote the time to implement. Most folk will likely see that build plugins run slowly and abandon the tool.

@MahdiBM
Copy link

MahdiBM commented Mar 10, 2025

FWIW the vscode extension will support specifying the build setting after this PR, which might or might not solve your problem depending on if you use vscode or would like to move to using it, or not.

This is of course only for command plugins. I see @dfed is using command plugins so this vscode extension PR could relate to him.

@dfed
Copy link
Contributor

dfed commented Mar 10, 2025

Nice @MahdiBM! My 2c is that slowness when running command plugins is less problematic (since they are by definition one-offs) than slowness running build plugins (since they run on and can be a bottleneck on every build). Nonetheless, I'm excited to see some movement here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement performance Performance optimizations and improvements
Projects
None yet
Development

No branches or pull requests

5 participants