[PATCH] Make clang tools ignore -fcolor-diagnostics and -fdiagnostics-color retrieved from the compilation database.

[Manuel Klimek]

On Wed, Jun 5, 2013 at 8:53 AM, David Blaikie <dblaikie at gmail.com> wrote:

> On Tue, Jun 4, 2013 at 1:11 PM, Alexander Kornienko <alexfh at google.com>
> wrote:
> > On Tue, Jun 4, 2013 at 10:04 PM, David Blaikie <dblaikie at gmail.com>
> wrote:
> >>
> >> On Tue, Jun 4, 2013 at 1:01 PM, Jordan Rose <jordan_rose at apple.com>
> wrote:
> >> >
> >> >   That's not right. What if I'm running my tool from the command line?
> >> > Better to just take those out of the compilation database.
> >>
> >> I've a slight tendency to agree - though I'm open to
> >> correction/countersuggestion: the compilation database only really
> >> needs the things that affect compilation. User-features (error limit?
> >> caret diagnostics? color diagnostics?) don't seem relevant to the
> >> database, but perhaps there's a use case I've not thought of. (or that
> >> no one has thought of - which would advocate in favor of leaving them
> >> in "just in case", perhaps)
> >
> >
> > Does it mean that you would better let compilation database filter out
> > flags? I'd say that this is not compilation database's responsibility.
> And
> > it will be needed in every compilation database implementation.
>
> The multiple implementation issue is a valid concern. Pity there's no
> way for Clang to tell the caller which args are relevant or somesuch.
> Oh well.
>

There's another design consideration - ultimately, the compilation database
should contain exactly what the build system does, which for MSVC would
contain MSVC arguments, and for gcc it's gcc arguments. To support this, we
have a layer on top of the compilation database: the argument adjusters. So
I think design wise this is exactly the right solution.

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130605/9aff5c47/attachment.html>