Luke Boswell (Jun 12 2024 at 10:38): Luke Boswell (Jun 12 2024 at 10:38):I propose we include the backend and linker in the build summary. I think this would help people understand why sometimes speeds are really fast, and other-times less so.
0 errors and 0 warnings found in 297 ms
with dev backend & surgical linker
0 errors and 0 warnings found in 5970 ms
with llvm backend & legacy linker
Yes, but maybe with dev compiler backend & surgical linker and with llvm compiler backend & legacy linkerwould be better. Later Roc will hopefully have more beginners to programming as a whole. If they see dev backendthey might just confuse it with their web server backend that they are trying to build.
Andres Villegas (Jun 12 2024 at 17:02):Would it be worth to display the time the backend and the linker took along side the total time?
Anton (Jun 12 2024 at 17:28):We have a flag for in-depth timing information, I think it's important to avoid printing too much info that is often irrelevant.
Brendan Hansknecht (Jun 12 2024 at 18:19):I wouldn't print any linker info
Brendan Hansknecht (Jun 12 2024 at 18:20):Just backend, cause that is more concretely useful
Brendan Hansknecht (Jun 12 2024 at 18:20):Really the user should never need to change the linker and it all eventually should be surgical or directly outputting a library
Brendan Hansknecht (Jun 12 2024 at 18:22):Why is my code running slow (oh, built with the dev backend)... Why is my code compiling close (oh, building in release)
Brendan Hansknecht (Jun 12 2024 at 18:22):Also, do not specify llvm. We should some users don't know what llvm is. Instead, release or similar.
Brendan Hansknecht (Jun 12 2024 at 18:23):So maybe just completed dev build in ... or completed release build in ...
Brendan Hansknecht (Jun 12 2024 at 18:24):Or 0 errors and 0 warnings found in 297ms (xxxx build)
Luke Boswell (Jun 12 2024 at 20:57):The main motivation for this change was actually so we know what linker was used. When you have a platfrom from URL it's not necessarily easy to know if it has binaries for the legacy or surgical linker or both, or for what architectures.
I think the cli should preference the surgical linker, fullback onto legacy. If the user provides a flag like linker=legacy and those files aren't available then give a warning.
Luke Boswell (Jun 12 2024 at 21:01):So maybe a better approach is just to print a warning whenever we use the legacy linker. Something like it's deprecated and will be replaced in future by the surgical linker.
Brendan Hansknecht (Jun 12 2024 at 23:48):What is the goal?
Is it:
Luke Boswell (Jun 13 2024 at 01:41):I think that is a good summary. All of those are beneficial in the short term before we have surgical linker for macos and windows, and platform support.
Brendan Hansknecht (Jun 13 2024 at 05:41):For 1, I think it might be reasonable. I don't think we should do it for 2 or 3
Last updated: Jun 16 2026 at 16:19 UTC