stdenv: enable colors #42932
stdenv: enable colors #42932
Conversation
|
@GrahamcOfBorg build aws-sdk-cpp |
|
Success on aarch64-linux (full log) Attempted: cmake Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: cmake Partial log (click to expand)
|
infinisil
force-pushed
the
cmake-colors
branch
2 times, most recently
from
8ab86d6
to
58742fe
Compare
|
Failure on x86_64-linux (full log) Attempted: aws-sdk-cpp Partial log (click to expand)
|
| @@ -93,6 +93,8 @@ fi | |||
|
|
|||
| addEnvHooks "$targetOffset" addCMakeParams | |||
|
|
|||
| export CLICOLOR_FORCE=1 | |||
There was a problem hiding this comment.
I think it makes sense to set this value here, because sometimes packages (e.g. the cmake one itself) use dontUseCmakeConfigure, but still use cmake with custom flags to configure it. These will have colored output too by exporting it here.
|
|
|
Failure on aarch64-linux (full log) Attempted: aws-sdk-cpp Partial log (click to expand)
|
I fail to get the meaning out of this sentence.
Learned something new :D I'll put the export in |
|
Success on x86_64-linux (full log) Attempted: cmake Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: cmake Partial log (click to expand)
|
Since the builds are running in the sandbox, there can't be a way for a tool like cmake to correctly detect whether the output is a tty or not, so colors will be disabled in all cases, even when you build with `nix-build` and see the lines scrolling by in your terminal. To have colors we therefore need to force it to use them with the dedicated CLICOLOR_FORCE env var for supported programs. This is somewhat of a standard, see https://bixense.com/clicolors/
| @@ -203,6 +203,8 @@ rec { | |||
| ++ optional (elem "host" configurePlatforms) "--host=${stdenv.hostPlatform.config}" | |||
| ++ optional (elem "target" configurePlatforms) "--target=${stdenv.targetPlatform.config}"; | |||
|
|
|||
| CLICOLOR_FORCE = 1; | |||
|
|
|||
There was a problem hiding this comment.
stdenv people: Please let me know if there's a better place to put it than here. It doesn't feel "right" here
There was a problem hiding this comment.
You could probably put it in impureEnvVars. At least, there are definitely times when you may not want colors, for instance in Eshell.
|
Success on x86_64-linux (full log) Attempted: stdenv Partial log (click to expand)
|
Sorry for being obscure! I imagine that a common scenario when
This idea sounds good! |
|
That's a good point, I haven't thought of that. @volth's idea of simulating (?) a terminal would certainly make it work correctly. An alternative not-as-nice solution to that would be to always unset |
|
Success on aarch64-linux (full log) Attempted: stdenv Partial log (click to expand)
|
|
The main issue with this is that none of the current web interfaces for viewing Nix build logs know what to do with ANSI escape codes. It will probably show up as something like when browsing a log in S3. Nixpkgs used to use ANSI escapes heavily (for nested build logs) but people always complained about this so I removed it. |
|
@edolstra It is however rather easy to strip color (https://stackoverflow.com/q/6534556/6605742), the other way is impossible, you can't add color once it's gone. Also this would allow colors in online viewers (by translating the codes to html) |
|
We can't strip or do any kind of processing when serving a log directly from S3. |
|
@edolstra I don't exactly know how logs get there in the first place, is there no command it uses to produce the logs? Oh and this just occured to me, an alternative which sounds much better: the Nix commands themselves could detect whether they output to a tty and strip color when it's not, along with full https://bixense.com/clicolors/ support. This would automatically propagate all colors when they would be there running the commands like normal. |
|
I'll close this for now, I think this would need some support from Nix itself to properly and nicely work (see comment above), for which I currently neither have the time or knowledge to implement it. |
Since the builds are running in the sandbox, there can't be a way for a
tool like cmake to correctly detect whether the output is a tty or not,
so colors will be disabled in all cases, even when you build with
nix-buildand see the lines scrolling by in your terminal.To have colors we therefore need to force it to use them with the
dedicated env var. Note that simply running
CLICOLOR_FORCE=1 cmake ...won't do it, we need to actually
exportit, so subprocesses can seeit.
I used
aws-sdk-cppto test it on (note that if you run cmake from this PR, it will first take a while to compile cmake itself, which will still be uncolored).Motivation for this change
Colors can be very useful to quickly spot errors/warnings in a build. Here is a recording of a comparison of a build with and without colors: https://asciinema.org/a/WNDtvyeRH5cDmq0EqiZrpN5M0
Things done
sandboxinnix.confon non-NixOS)nix-shell -p nox --run "nox-review wip"./result/bin/)nix path-info -Sbefore and after)