[Chapel Merge] Change one more mason output to use writeln

chapelhpcBot · December 9, 2025, 10:38pm

Branch: refs/heads/main
Revision: 42d4ae6c92a2fd174dbf37857c407e19b37c1cd0
Author: e-kayrakli
Link: Change one more mason output to use writeln by e-kayrakli · Pull Request #28164 · chapel-lang/chapel · GitHub
Log Message:
Change one more mason output to use writeln (#28164)

Changes one more logger usage to writeln as it broke testing.

More principled solution on this is being discussed under

github.com/chapel-lang/chapel

Mason console output contents and how it should be tested

opened 08:41PM - 09 Dec 25 UTC

e-kayrakli

type: Design area: Tools

Before my #27857, I had found mason's default output to be a bit random, where s…ome of the messages printed out on the console felt too developer-oriented, while I felt some important information to be lacking. As part of that PR, I added a relatively more advanced capability to print out more information on the console with more control on verbosity. That PR switches to that new strategy only partially. However, that still caused many tests failures as existing mason testing locks in the console output from mason. In my follow up PR #28139, I added `MASON_QUIET` environment variable to quiet down the new logger as a band aid. That caused some output to be removed from the `good` files, which I think was appropriate in any case (to me, it was just cluttering the output). However, to be able to quickly quiet down nightly failures, I also reverted some of #27857 to go back to writelns such that good files match. It seems like, we still need to make some more reversions as of today. This issue is to discuss a more principled approach for mason's console output and how mason testing works. My opinions on the matter, in rough order of how strong I feel about it: - Mason needs multiple levels of verbosity in its output. - That control should not be based on subcommands, but on `mason` itself. - Except for a limited set of testing specifically for console output, we should _not_ lock in console output as part of our correctness testing. Especially considering mason not being very mature, having many good files with console output feels like a recipe for slowing down development to me. - We can and should lock in the output from applications (e.g. with `mason run`) and testing (e.g. with `mason test`), though. - The band-aid I put in with `MASON_QUIET` should not be a long-term solution, however, we can imagine multiple levels of verbosity to be "passed" via environment variables. - More mason testing should use shell-based launches so that verbosity can be controlled more easily. --- Right now, this leaves out the important discussion on what should we do with the existing testing and good files. I think we can find a relatively low-effort way to modernize them.

[Trivial, not reviewed]

Test:

failing tests pass on darwin
linux64 in test/mason

Compare: Comparing b00d5a82edbd13d622f5d9a03a0d676c67b69dec...76cc9e4e258e8302d7b00df0cd65f9e0bc6c3a77 · chapel-lang/chapel · GitHub

Diff:
M tools/mason/MasonBuild.chpl
M tools/mason/MasonUpdate.chpl
https://github.com/chapel-lang/chapel/pull/28164.diff