This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: diag color
- From: phi gcc <phi dot gcc at gmail dot com>
- To: Markus Trippelsdorf <markus at trippelsdorf dot de>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 31 Jul 2016 10:46:41 +0200
- Subject: Re: diag color
- Authentication-results: sourceware.org; auth=none
- References: <CADieKzu2BhHBTzhWrQjuCCZixd7bnq2syB=z+8JvXbeFL2L6FQ@mail.gmail.com> <20160731062539.GA313@x4>
Hi,
Well, I can't 'easilly' change the makefiles I am using, they are not
mine,meaning I would have to 'patch' any build env Makefile each time
we do a refresh of the app sources. Then some gcc version don't
understand the -fno-diagnostics-color meaning the makefile patch would
have to be GCC version aware, that is a bit of a mess, and as you said
the vast majority use vt100, so those could have colors if they want
to.
While a simple getenv("TERM") to setup the default of the color
predicate before going to the sequence of testing CFLAGS, et the
optargs, would cost almost nothing.
I am not convince, ethically speaking, with the 'vast majority' concept.
I am more inclined by complexity, stabililty, risk vs benefit.
Here the risk is nil, benefit very moderate ==> easy to do.
With a cancer like propagation, vast majority use gcc, that impose
vt100, then by now the vast majority got rid of term so lets remove
termcap/terminfo. Hum... I don't really like this approach.
Cheers,
Phi