On Tue, Jun 4, 2013 at 10:11 PM, Alexander Kornienko <[email protected]>wrote:
> On Tue, Jun 4, 2013 at 10:04 PM, David Blaikie <[email protected]> wrote: > >> On Tue, Jun 4, 2013 at 1:01 PM, Jordan Rose <[email protected]> >> 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. > My point of view is that it should not be the compilation database's responsibility : it just can not know what has to be filtered or not for the user --- the filtering should be left to the compilation database user. For the vim case, clang_complete has such a filtering implemented. I did commit r182878 --- which introduced this change --- and it can be reverted : arguably, we can consider that either ninja or clang need to be fixed for proper color handling / terminal capabilities detection. > _______________________________________________ > cfe-commits mailing list > [email protected] > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
