-no-color option doesn't do anything

[Khady]

Launching bsb using yarn run bsb -make-world -no-color produces the same output with colors than yarn run bsb -make-world.

[bobzhang]

I think -no-color is not an option to bsb, but it seems we should warn on such unused parameter.
curious when do you want -no-color

[Khady]

 $ ~/.yarn/bin/bsb -help
Usage : bsb.exe <bsb-options> -- <ninja_options>
For ninja options, try ninja -h 
ninja will be loaded either by just running `bsb.exe' or `bsb.exe .. -- ..`
It is always recommended to run ninja via bsb.exe 
Bsb options are:
  -v  Print version and exit
  -version  Print version and exit
  -verbose  Set the output(from bsb) to be verbose
  -color  forced color output
  -no-color  forced no color output
  -w  Watch mode
  -clean-world  Clean all bs dependencies
  -clean  Clean only current project
  -make-world  Build all dependencies and itself 
  -init  Init sample project to get started. Note (`bsb -init sample` will create a sample project while `bsb -init .` will reuse current directory)
  -theme  The theme for project initialization, default is basic(https://github.com/bucklescript/bucklescript/tree/master/jscomp/bsb/templates)
  -regen  (internal) Always regenerate build.ninja no matter bsconfig.json is changed or not (for debugging purpose)
  -query  (internal)Query metadata about the build
  -themes  List all available themes
  -where  Show where bsb.exe is located
  -help  Display this list of options
  --help  Display this list of options
$ ~/.yarn/bin/bsb -version
4.0.3

It looks like a bsb option.

I want no color when I compile in emacs (because emacs can parse the output and do smart things with it) or redirect the output to a file.

[bobzhang]

note the output could come from bsb.exe, bsc.exe and ninja.exe.
The current -no-color option would suppress color from bsb.exe, which seems not ideal

[Khady]

Yes, it would be nice to remove the colors from the whole chain. If bsc follows the same convention than the ocaml compiler, then it is already good. I don't know about ninja.

[bobzhang]

After some thoughts, from the point of the view of the build system, I think it is a mistake to expose such flag, there are multiple reasons for this

1. adding a color flag should not trigger rebuild, i.e, we should not do a clean and rebuild to get the color

To make color configurable, we are going to piggy back the existing environment variable, NINJA_ANSI_FORCED.

When NINJA_ANSI_FORCED is set 1, bsb.exe will produce colors, ninja.exe will produce colors and preserve the ANSI code by bsc.exe, note bsc.exe will be passed flag "-color always"

When NINJA_ANSI_FORCED is set 0, bsb.exe will not produce colors, ninja.exe will not produce colors and it will try to strip ANSI code by bsc.exe, note bsc.exe will still be passed a flag "-color always"

When NINJA_ANSI_FORCED is unset, bsb.exe will produce colors based on terminal test, this is the same with ninja.exe, note bsc.exe will still be passed a flag "-color always"

The take away is that bsc.exe will be always passed a flag "-color always", it will be determined in the runtime to strip ansi code or not, so that the build system(generated build.ninja) will not be affected.