bug-standards
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Environment variable to turn off carets


From: Frank Heckenbach
Subject: Re: Environment variable to turn off carets
Date: Sun, 11 Jan 2015 00:43:11 +0100

>    address@hidden @code{NO_CARET_OUTPUT}, environment variable
>    +If you want to indicate error positions with a caret (e.g., GCC's
>    address@hidden option), you should suppress this
>    +indication if the environment variable @code{NO_CARET_OUTPUT} is
>    +defined (even if it is defined with a null value).
> 
> These things come to my mind,
> 
>  1) no program today supports this variable.

That's why I'm suggesting to add it. One has to start somewhere.
(As I said, I tried to start with one program (bison), but they sent
me here.)

>  2) all programs that have ADA like caret error messages need to be
>     updated.

Sure, but it's a small change.

>  3) I don't think there is any precedence to use environment variables
>     to change the output in this manner.

What about GCC_COLORS?

> 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.

> There is already precedence with
> auotoconf's --with/--without and --enable/--disable options being
> silently ignored in older versions, and in newer where they produce a
> warning message.  But this is alot of work, and can break old
> behaviour.

(Probably more work that just checking getenv("NO_CARET_OUTPUT").)

> 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.

> 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).

Frank



reply via email to

[Prev in Thread] Current Thread [Next in Thread]