On Wed, Jun 5, 2013 at 8:53 AM, David Blaikie <[email protected]> wrote:
> On Tue, Jun 4, 2013 at 1: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. > > 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
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
