On Wed, Aug 21, 2013 at 8:48 AM, Thompson, John <
[email protected]> wrote:

>  Sean,****
>
> ** **
>
> (Sorry for the delay in getting back to you, I had a fire to put out
> elsewhere.)****
>
> ** **
>
> >Is there no better way to do this? I think libOption should expose the
> info you need.****
>
> ** **
>
> This would seem to have a prerequisite that ClangTooling have a OptTable
> somewhere, but there doesn’t seem to be a connection.****
>
> ** **
>
> Now let’s suppose I get past that hurdle, either by creating one myself
> and somehow coercing it to parse the arguments given to ArgumentsAdjuster,
> how do I use libOption to walk the arguments and figure out which
> command-line argument is the source file?
>

Maybe look at how the clang driver/frontend does it?


> ****
>
> ** **
>
> Ideally, tooling should have a mechanism to tell me what the source file
> or files are for each command line in the compilation database.  I had a
> much simpler version, but it required I modify ArgumentsAdjuster to be
> given the source file, which the caller had handy, but I couldn’t get that
> change through.
>

The JSON compilation databases have a "file" key which contains just the
filename. Maybe that could help?

-- Sean Silva


> ****
>
> ** **
>
> Could someone associated with tooling lend a hand and tell me how to get
> the input file from the command lines in the compilation database?****
>
> ** **
>
> Otherwise, let’s live with the less-than-perfect solution so I can go on
> to more important things.****
>
> ** **
>
> Thanks.****
>
> ** **
>
> -John****
>
> ** **
>
> ** **
>
> *From:* Sean Silva [mailto:[email protected]]
> *Sent:* Friday, August 16, 2013 10:59 PM
> *To:* Thompson, John
> *Cc:* [email protected]
> *Subject:* Re: [PATCH] Header dependencies support for modularize****
>
> ** **
>
> +// The most common (but not all) options to modularize that take****
>
> +// an argument in the following slot.****
>
> +// Note: This needs to be kept in sync with new or removed Clang
> arguments.****
>
> +// But hopefully modularize users won't need too many of these****
>
> +// kinds of arguments.****
>
> +const char *AddDependenciesAdjuster::OptionsWithArgument[] = {****
>
> ** **
>
> Is there no better way to do this? I think libOption should expose the
> info you need.****
>
> ** **
>
> -- Sean Silva****
>
> ** **
>
> On Fri, Aug 16, 2013 at 8:42 AM, Thompson, John <
> [email protected]> wrote:****
>
> A quick review anyone?****
>
>
> Thanks.
>
> -John
>
> -----Original Message-----
> From: [email protected] [mailto:
> [email protected]] On Behalf Of John Thompson
> Sent: Tuesday, August 13, 2013 11:11 AM
> To: [email protected]
> Cc: [email protected]
> Subject: [PATCH] Header dependencies support for modularize****
>
> In using modularize to check a large group of platform headers for
> modules-readiness, I found that a few headers had dependencies, such that
> they required other headers to be included first to avoid compile errors on
> missing definitions.
>
> This patch adds support to modularize to allow specifying depended-on
> headers in the header file list input to modularize, i.e.
>
> header.h: dependency1.h dependency2.h
>
>
> http://llvm-reviews.chandlerc.com/D1383
>
> Files:
>   test/modularize/NoProblemsDependencies.modularize
>   test/modularize/Inputs/SomeOtherTypes.h
>   test/modularize/Inputs/IsDependent.h
>   modularize/Modularize.cpp****
>
> _______________________________________________
> 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

Reply via email to