This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Environment variable to turn off carets


This is a copy of the suggestion I made in
http://lists.gnu.org/archive/html/bug-standards/2015-01/msg00001.html
Karl Berry suggested I ask for your views first.


Various programs (including gcc and bison) support caret error
messages, and recent versions have it activated by default.

Caret output is a useful feature in many cases, but sometimes it's
not helpful. E.g. when your editor parses the line/column numbers
from the output and automatically jumps to this position, additional
caret output is not needed, and indeed rather wastes space in the
list of output messages. For other users, caret output just wastes
screen-space, e.g.:
http://stackoverflow.com/questions/19341149/turning-off-error-message-caret-in-gcc-4-8

Sure, you can turn off carets with command-line options such as
"-fno-diagnostics-show-caret" (gcc) or "-fno-caret" (bison). But
before you do that, you need a version check, since older versions
don't understand these options and would fail. Also, the options
differ between tools as shown for gcc and bison. At some time, the
next tool, perhaps flex, will get carets and you need yet another
option and version check, etc. ...

Now, suppose your build runs from a Makefile (which contains various
gcc, bison, etc. invocations), and you want to use the Makefile from
an arbitrary context (e.g. plain command line where you want carets,
and from the editor where you don't). Now, you have to pass some
variable to the Makefile to tell it whether to do those version
checks and pass the respective options to gcc, bison, etc. And you
need to do this in every relevant Makefile. This all gets a bit
cumbersome ...

So let me suggest an alternative:

If all programs that support caret output would recognize a common
environment variable (say "NO_CARET_OUTPUT"), all of the above
complications would disappear:

- No version checks are required, since older versions simple ignore
  the variable.

- One doesn't even have to know which programs (gcc, bison, maybe
  flex etc.) support carets if they use a common variable.

- The Makefiles don't have do to anything since environment
  variables are automatically propagated. Only the editor, i.e. the
  instance that actually knows that carets are not useful there,
  needs to set the variable once. (So not only DRY, but also SOC, to
  drop some TLAs. ;)

Does this seem reasonable?

Regards,
Frank


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]