Re: Environment variable to turn off carets

[Frank Heckenbach]

>    > It would be far easier to, I think, in the long run specially, to
>    > amend the behaviour of -fxxx type of options where they would
>    > produce a warning instead of a hard error.
> 
>    This part of the problem is about giving this option where an old
>    version is installed, and old versions of gcc and bison fail hard.
>    You cannot change old versions retroactively.
> 
> True, which is why it would be a long term change.

An important part of my suggestion is explicitly about the
short-term problems for the time where we'll have old and new
versions (i.e. with and without caret options) on different
machines. In the long term, they'll all have them, and only the
smaller problem of differently named options would remain.

>    > To have different behaviour between compilation runs, I would
>    > recommend creating a config.site file that one uses whith the
>    > specific settings.
> 
>    It's not necessarily site-wide. I may, e.g. build one thing within
>    an editor where I don't want carets, and simultaneously something
>    else on the command-line where I do. It's "job"-wide, and
>    environment variables have exactly the right scope for this.
> 
> config.site can be site wide, you can also have something like,
> 
> if $NO_CARET; then
>   FLEXFLAGS=-fno-caret
>   CFLAGS=-fno-diagnostics-caret
> fi
> 
> In there to enable/disable things more easily.

Which would break if you have an old flex/gcc version which doesn't
understand the option. So you need version checks, or you need to
amend config.site when you upgrade them.

Besides, what you do seems to avoid the "official" environment
variable I suggest, only to reintroduce it thorugh the back door.
Once such a config.site becomes widespread as you suggest below, the
variable name would essentially be reserved anyway.

>    > In which you can pass the correct flag to the respective
>    > programs.  This has the benefit that for the programs that do
>    > have ADA caret output, but do not support this environment
>    > variable, you can still silence it.
> 
>    The user would still need to check each program (regularly after
>    updates) to find out which of them have such options and what
>    they're called in each case. That's an unnecessary burden on the
>    user. The programs themselves know very well what they support in
>    each version, and adding the environment variable check is a
>    one-time job per program (vs. once per user, program, and version).
> 
> Yes, but the user would have to do that anyway, in the cases where you
> still get caret output.  I would be quite confused if I get caret
> output despite saying that I don't want it.

Sorry, can't follow you here. In my suggestion, why would you get
caret output despite saying that you don't want it?

> Not against the idea, just wondering if there might be a better way of
> doing this that will work with other similar features.  You brought up
> one such example, with GCC_COLORS.  Adding a dozen different
> environment variables every time one wishes to modify the behaviour of
> various programs seems like a slipery slope.
>
> Do we add a NO_WARNINGS?

I think the situation is a bit different. First, warnings are not
something new, i.e. all programs that can output warnings have been
doing so (and have had options to suppress them) for a long time.
Whereas carets are new and pushed on the user (by an upgrade)
whether or not they want them, only to have them find out how to
suppress them, differently for each program. Also, IME you don't
often switch between building a project with or without warnings
because they say something about the state of the project, whereas
carets (and color) are entirely forms of presentation, independent
of details of the project.

That said, I wouldn't object to such a variable, but I'm not
actively suggesting to introduce it.

> NO_OUTPUT?

Sure, it's called ">/dev/null 2>&1". :)

Point is, there's an existing way that works for everything already,
unlike suppressing carets.

> Maybe just keeping a config.site file that users can install would
> be much easier, it could be part of the GNU coding standards, as
> an example, or someone else could maintain it.  The benefit of
> that is that _all_ programs can have supressed output of some sort
> -- not just programs that support NO_CARET_OUTPU.

What I gather from this is, that the proposal might be generalized a
little. Instead of just dealing with carets, the variable could say
"no redundant output" or something to this effect. Meaning that the
output will be processed or interpreted by a tool rather than
directly read by a human.

If there is consensus, I'd be happy with such a variable too. It
would be a similar proposal, apart from a new name and different
wording in the standards. As for implementation, suppressing carets
would still be the first (and possibly only, at least for now) thing
that gcc, bison etc. should do.

Regards,
Frank