converting a LibTooling tool to a library

Hi,

I've written a simple command-line code-mutation tool using the Tooling
infrastructure [1]. The tooling framework handled many of the difficult
portions of this task (handling compilation databases etc...) allowing
me to focus on writing a RecursiveASTVisitor -- my thanks to everyone
who worked on the tooling setup and on clang in general.

I would now like to expose the functionality of this ASTVisitor as a C
library so that I can call these functions programatically and chain
multiple ASTConsumers without the overhead of multiple shell calls,
repeatedly parsing of the original source, etc...

Is this possible? Is this difficult? Is there a best practice for
transitioning from a command-line Tooling tool to a library? Should I
just look though the clang/Tooling source? Any pointers or suggestions
would be greatly appreciated.

Thanks,

Footnotes:
[1] https://github.com/eschulte/clang-mutate

Hi,

I've written a simple command-line code-mutation tool using the Tooling
infrastructure [1]. The tooling framework handled many of the difficult
portions of this task (handling compilation databases etc...) allowing
me to focus on writing a RecursiveASTVisitor -- my thanks to everyone
who worked on the tooling setup and on clang in general.

:slight_smile:

I would now like to expose the functionality of this ASTVisitor as a C

library so that I can call these functions programatically and chain
multiple ASTConsumers without the overhead of multiple shell calls,
repeatedly parsing of the original source, etc...

Is this possible? Is this difficult? Is there a best practice for
transitioning from a command-line Tooling tool to a library? Should I
just look though the clang/Tooling source? Any pointers or suggestions
would be greatly appreciated.

I think you're the first one to go this route - one thing I notice is that
you say "C library". I assume that's a requirement? In general, the way I'd
go about this is:
- build a C++ library
- build a C wrapper that exposes the functionality

That's pretty much the way libclang does it (minus some stuff that's only
in libclang, but we've already noticed some of that stuff would be very
nice to have in a C++ layer).

Your tool is also sufficiently narrow focus currently that I think it might
make sense to go into clang mainline as a library and be useful from
libclang, but Doug might have a different opinion.

Thanks,

Footnotes:
[1] https://github.com/eschulte/clang-mutate

Nice! Looks awesome :slight_smile:
/me wonders whether it would be a perfect fit for the extra-tools
repository...

Cheers,
/Manuel

Manuel Klimek <klimek@google.com> writes:

Hi,

I've written a simple command-line code-mutation tool using the Tooling
infrastructure [1]. The tooling framework handled many of the difficult
portions of this task (handling compilation databases etc...) allowing
me to focus on writing a RecursiveASTVisitor -- my thanks to everyone
who worked on the tooling setup and on clang in general.

:slight_smile:

I would now like to expose the functionality of this ASTVisitor as a C

library so that I can call these functions programatically and chain
multiple ASTConsumers without the overhead of multiple shell calls,
repeatedly parsing of the original source, etc...

Is this possible? Is this difficult? Is there a best practice for
transitioning from a command-line Tooling tool to a library? Should I
just look though the clang/Tooling source? Any pointers or suggestions
would be greatly appreciated.

I think you're the first one to go this route - one thing I notice is that
you say "C library". I assume that's a requirement? In general, the way I'd
go about this is:
- build a C++ library
- build a C wrapper that exposes the functionality

Great, I'll take this approach. Hopefully it won't be overly difficult
to pull the relevant preparatory code (source -> AST conversion) out of
the existing Tooling libraries.

That's pretty much the way libclang does it (minus some stuff that's only
in libclang, but we've already noticed some of that stuff would be very
nice to have in a C++ layer).

Your tool is also sufficiently narrow focus currently that I think it might
make sense to go into clang mainline as a library and be useful from
libclang, but Doug might have a different opinion.

I initially hoped to use libclang for this work but found it did not
include any Code Rewriting functionality. I don't know if my ASTMutate
library is the best abstraction around code rewriting, but I would love
to see some rewriting support in libclang.

Thanks,

Footnotes:
[1] https://github.com/eschulte/clang-mutate

Nice! Looks awesome :slight_smile:
/me wonders whether it would be a perfect fit for the extra-tools
repository...

This does seem like it could be a nice fit. If the extra-tools repo
would like to include this mutation tool then I'm happy to help with the
integration, just let me know what I can do.

Thanks,

Manuel Klimek <klimek@google.com> writes:

>
>> Hi,
>>
>> I've written a simple command-line code-mutation tool using the Tooling
>> infrastructure [1]. The tooling framework handled many of the difficult
>> portions of this task (handling compilation databases etc...) allowing
>> me to focus on writing a RecursiveASTVisitor -- my thanks to everyone
>> who worked on the tooling setup and on clang in general.
>>
>
> :slight_smile:
>
> I would now like to expose the functionality of this ASTVisitor as a C
>> library so that I can call these functions programatically and chain
>> multiple ASTConsumers without the overhead of multiple shell calls,
>> repeatedly parsing of the original source, etc...
>>
>> Is this possible? Is this difficult? Is there a best practice for
>> transitioning from a command-line Tooling tool to a library? Should I
>> just look though the clang/Tooling source? Any pointers or suggestions
>> would be greatly appreciated.
>>
>
> I think you're the first one to go this route - one thing I notice is
that
> you say "C library". I assume that's a requirement? In general, the way
I'd
> go about this is:
> - build a C++ library
> - build a C wrapper that exposes the functionality
>

Great, I'll take this approach. Hopefully it won't be overly difficult
to pull the relevant preparatory code (source -> AST conversion) out of
the existing Tooling libraries.

>
> That's pretty much the way libclang does it (minus some stuff that's only
> in libclang, but we've already noticed some of that stuff would be very
> nice to have in a C++ layer).
>
> Your tool is also sufficiently narrow focus currently that I think it
might
> make sense to go into clang mainline as a library and be useful from
> libclang, but Doug might have a different opinion.
>

I initially hoped to use libclang for this work but found it did not
include any Code Rewriting functionality. I don't know if my ASTMutate
library is the best abstraction around code rewriting, but I would love
to see some rewriting support in libclang.

>
>
>> Thanks,
>>
>> Footnotes:
>> [1] https://github.com/eschulte/clang-mutate
>
>
> Nice! Looks awesome :slight_smile:
> /me wonders whether it would be a perfect fit for the extra-tools
> repository...
>

This does seem like it could be a nice fit. If the extra-tools repo
would like to include this mutation tool then I'm happy to help with the
integration, just let me know what I can do.

http://clang.llvm.org/docs/ClangTools.html

Cheers,
/Manuel