[cfe-dev] Getting involved with Clang refactoring

[Matthieu Monrocq]

On Thu, May 24, 2012 at 6:17 PM, Manuel Klimek <klimek at google.com> wrote:

> On Thu, May 24, 2012 at 5:42 PM, Bill White <bill.white at griggsinst.com>wrote:
>
>> I'm following this discussion closely, as I'm working on a very
>> similar constellation
>> of problems.  I'm interested in clang_complete and some form of clang
>> indexing,
>> but for emacs, not for vim.  I'm thinking that the indexing tool
>> should be something
>> like ctags or gid, but smarter.  I'm working on a python tool to
>> extract build information
>> from the output of gmake.  (FWIW, I think I have management interest
>> in contributing
>> my code to clang, or emacs, or whatever my code ends up being useful for.)
>>
>> Does anybody know if the uses of the compilation database cares about the
>> first parameter in the command?  What I'm asking is, if I interpose my
>> command,
>> say mk_compile_db, for a call to g++, and then do gmake --makeall
>> CC=mk_compile_db...
>> the compilation command will say that mk_compile_db is the command, not
>> g++.
>> It turns out that the path to g++ is explicit in our build system, so
>> I can't just change
>> the first word to "g++" and give an accurate answer.  On the other
>> hand, maybe it
>> doesn't matter what the command is.  Maybe the libtooling facilities
>> ignore the
>> first word, or maybe they expect the first word to be elided altogether.
>>
>
> Yes, they ignore argv[0].
>
> Cheers,
> /Manuel
>
>
>> I could investigate the code, but I think I'd rather know what the
>> intended behavior is.
>>
>> On Thu, May 24, 2012 at 10:11 AM, Arnaud de Grandmaison
>> <arnaud.allarddegrandmaison at parrot.com> wrote:
>> > On 05/24/2012 02:28 PM, Manuel Klimek wrote:
>> >> In the end it depends on who's willing to write which solution and
>> >> propose a patch to clang ;)
>> > Do not tempt me ;)
>> >
>> > The use case I have here is that several people are using clang_complete
>> > + vim, but have to use gcc because their target requires it. We have
>> > added a cmake target to generate the ".clang_complete" configuration
>> > file, which provides the options necessary for compiling the source
>> > files :  in essence, that's a compilation-db. On its side,
>> > clang_complete also provides a script to extract the compilation options
>> > from the build system.
>> >
>> > I am interested in working on this compilationdb, as this will clearly
>> > be a benefit for clang and all derivative projects.
>> >
>> > Cheers,
>> >
>> > --
>> > Arnaud de Grandmaison
>> > Senior CPU engineer
>> > Business Unit Digital Tuner
>> >
>> > Parrot S.A.
>> > 174, quai de Jemmapes
>> > 75010 Paris - France
>> > Phone: +33 1 48 03 84 59
>> >
>>
>>
I would personally favor the use of the Clang flag or an interposition
script to write into the compilation database.

I don't buy the "building with another compiler" issue as even for such
codebases, one can easily run clang with -fsyntax-only and discard the
output or a specific -fdo-nothing could be added and ignored by the tool.

I see only two issues:
- locking, which would reduce performance
- distributed builds: when the compiler is invoked on various machines, how
do you centralize the generated information ?

And I don't think that it is worth worrying too much about them. The
creation of the compilation database is a one-off operation so performance
is not too much of an issue, and people having the resources to set up such
distributed builds should have the resources to configure their build to
run on a single machine and/or write scripts to create the database by
themselves.

-- Matthieu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120524/a3fc58c6/attachment.html>