I've made a patch to pass -color on
to coqc when Dune detects it can enable color outputs itself. This should lead to prettier error messages for users. I would appreciate if people tried it out: https://github.com/ocaml/dune/pull/7052
if I run dune build in a color capable terminal, then again in a color incapable terminal, does it detect that the coqc command changed and rebuild?
That's a good point...
I believe it would rebuild.
The color options are passed to ocamlc using an env var. Do we have something similar for coqc?
Btw, this would not affect the core coq as we generate our own rules there.
I see we have COQ_COLOR, but that is probably not what we are after right?
also does auto colors not work when called through dune?
I originally tried that, but it didn't work in my terminal.
Color detection in other binaries is also off by default, since I guess Dune is piping outputs.
If we had an enviornment var like OCAML_COLOR
that would be the ideal solution.
Ali Caglayan said:
I see we have COQ_COLOR, but that is probably not what we are after right?
I see COQ_COLORS (plural) but not COQ_COLOR
we could add COQ_COLOR
OTOH using env vars to get around dune feels like a hack
maybe dune should have a system to understand flags that don't affect the actual targets?
If you set CLI_COLOR
you can turn off Dune's auto color detection, which should help people in the situation of switching between a color and non-color terminal.
For most people, Dune will be called inside a color terminal and there won't be a switch of enviornment.
I'll see what the other devs think about the situation.
CI need not be a color terminal... But I'd say we do need smarter caching for other reasons
https://github.com/ocaml/dune/issues/6005 / https://github.com/ocaml/dune/pull/6006 is the example I have in mind
@Gaëtan Gilbert I'd expect auto-colors can't work in dune because dune always buffers the output (like make -O
) to avoid mixing outputs from multiple commands in concurrent builds
Paolo Giarrusso said:
https://github.com/ocaml/dune/issues/6005 / https://github.com/ocaml/dune/pull/6006 is the example I have in mind
This is on my radar, but I still don't know a good way of fixing those error messages for users other than parsing and fixing.
In anycase after discussing with some of the Dune devs, I don't think we will ever have a way of ignoring command line arguments in Dune. I don't think the environment variable solution is too hacky, so I would like for Coq to implement CLI_COLOR eventually.
For now, passing the argument is unlikely to affect many users.
I agree environment variables are reasonable, especially if dune can commit to not tracking them.
Re "many users": wouldn't this affect IDEs when they switch to dune coq top?
Yes, this is true. Perhaps some more thinking is needed on this feature.
Currently there are good workarounds too like setting -color
from env.
Ah by wrapping coqc you mean like this?
https://gitlab.mpi-sws.org/iris/refinedc/-/blob/master/dune#L4
https://gitlab.mpi-sws.org/iris/refinedc/-/blob/master/tools/coqc_timing.sh
I've have to do this quite a bit, indeed
@Ali Caglayan also, I didn't link the !6006 MR because of the error-message problem, but because caching is too strict for it to work
I don't mean overriding the coqc binary, but you can do (env (_ (coq (flags -color on))))
.
btw Dune uses some path rewriting hackery to get ocamlc builds to be relocatable. However this screws with other tools such as ocamldebug.
Last updated: Jun 04 2023 at 23:30 UTC