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