A template refactoring tool

Now that we have a place for "extra" tools, I have one.

It's a spectacularly useless refactoring tool, since it doesn't match any code patterns and doesn't change any of the things that it doesn't find.

However, for people wanting to write a refactoring tool, it gives them a place to start, with comments indicating where their code should go.

What else needs to go here?

-- Marshall

Marshall Clow Idio Software <mailto:mclow.lists@gmail.com>

A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait).
        -- Yu Suzuki

refactoringTemplate-1.patch (6.33 KB)

Marshall Clow wrote:

Now that we have a place for "extra" tools, I have one.

We do? Did I miss a message to this list about it or did it go somewhere
else?

Marshall Clow wrote:

> Now that we have a place for "extra" tools, I have one.

We do? Did I miss a message to this list about it or did it go somewhere
else?

I don't think an announcement has gone out yet. The SVN repository can be
found at https://llvm.org/svn/llvm-project/clang-tools-extra/trunk/, which
should be checked out into clang/tools/extra/. I also believe documentation
is on its way. Here's the commit message from r161405:

Initial support for recursing into the new clang-tools-extra repository
if checked out under clang/tools/extra.

This is mostly so folks other than me can start to test. Documentation,
details, and an announcement are still in the works.

I hope this helps.
-Sam

Chandler posted this link in #llvm yesterday:

http://llvm.org/svn/llvm-project/clang-tools-extra/trunk

I'm not sure if any other announcement has been made.

CC'ing Chandler since I think he's the one that created it and can
probably provide more info.

--Sean Silva

Everyone hang on. =] I wanted to give folks some time to play with it, fix
some issues, write docs, and actually get the rest of this thing set up.

Let's not go crazy with code reviews at this point please. =D I'll send an
announcement when it's ready for wider use.

Chandler Carruth wrote:

Chandler posted this link in #llvm yesterday:

http://llvm.org/svn/llvm-project/clang-tools-extra/trunk

I'm not sure if any other announcement has been made.

Everyone hang on. =] I wanted to give folks some time to play with it,

Can I request that a CMake only buildsystem is fine for this tooling repo? I
don't want to have to write and maintain custom Makefiles for 'extra' tools.

This is not such a central piece of clang that there is any need to maintain
two buildsystems for it, is it?

In particular, I would want to write a Qt based ui for some tooling, and I
wouldn't want to maintain a Makefile buildsystem for that (CMake generates
moc files automatically and ui files easily).

If you really want a Makefile based buildsystem in there, then please make
sure that is optional and a decision for the tool maintainer.

Thanks,

Steve.

Chandler Carruth wrote:

Chandler posted this link in #llvm yesterday:

http://llvm.org/svn/llvm-project/clang-tools-extra/trunk

I'm not sure if any other announcement has been made.

Everyone hang on. =] I wanted to give folks some time to play with it,

Can I request that a CMake only buildsystem is fine for this tooling repo? I
don't want to have to write and maintain custom Makefiles for 'extra' tools.

The plan is to provide yet another repository (on github) that
basically behaves like extra, but is called 'external'. The idea is
that developers writing their own tools will just fork that, check
their fork out and start hacking away, with all the cool git features.
If a tool provides a solid design a good idea for the use case and
maintenance story, we can then move tools to the extra repository (at
which point we'll need Makefiles).

As long as you're in an external branch, you'll be free to not write
Makefiles for your tools.

This is not such a central piece of clang that there is any need to maintain
two buildsystems for it, is it?

In particular, I would want to write a Qt based ui for some tooling, and I
wouldn't want to maintain a Makefile buildsystem for that (CMake generates
moc files automatically and ui files easily).

I think that would be a perfect fit for the "external" repository use case.

Cheers,
/Manuel

Manuel Klimek wrote:

Can I request that a CMake only buildsystem is fine for this tooling
repo? I don't want to have to write and maintain custom Makefiles for
'extra' tools.

The plan is to provide yet another repository (on github) that
basically behaves like extra, but is called 'external'.

That sounds pretty awful to me. So you want two new repos: an extra repo and
an extra-extra repo. Why not just one extra repo? Who decides what goes into
what repo? Is the extra repo more 'blessed' than the extra-extra repo? Will
the extra-extra git repo be ported to API changes that happen in llvm/clang,
or will only the extra one be ported (as part of doing the actual API
change)?

Thanks,

Steve.

Manuel Klimek wrote:

Can I request that a CMake only buildsystem is fine for this tooling
repo? I don't want to have to write and maintain custom Makefiles for
'extra' tools.

The plan is to provide yet another repository (on github) that
basically behaves like extra, but is called 'external'.

That sounds pretty awful to me. So you want two new repos: an extra repo and
an extra-extra repo. Why not just one extra repo? Who decides what goes into
what repo? Is the extra repo more 'blessed' than the extra-extra repo? Will
the extra-extra git repo be ported to API changes that happen in llvm/clang,
or will only the extra one be ported (as part of doing the actual API
change)?

Yes, 'extra' is the blessed repo. 'external' will just be to get
people a quick way to integrate their own independent tools. Mid-term
we'll want to actually get a real install of the clang libs (at least
if I understood Doug correctly :wink: so that you can use an installation
of clang from your CMakeLists.txt and be done with it instead of
needing to follow trunk.

Especially for the API changes we'll not be able to do that for all
tools that are out there, which I hope is understandable :slight_smile:

Cheers,
/Manuel

Manuel Klimek wrote:

I think that would be a perfect fit for the "external" repository use
case.

If it's in the extra-extra repo, then it can't compile the tools from the
extra repo in. It can only invoke them through IPC. The whole point of
putting the gui together with the code would be to avoid the IPC and be able
to do more 'at once'.

Eg, if the for loop refactoring tool is in the blessed extra repo and the
gui is not, then that tool can't be part of the gui.

Thanks,

Steve.

Manuel Klimek wrote:

Especially for the API changes we'll not be able to do that for all
tools that are out there, which I hope is understandable :slight_smile:

Not porting 'all tools out there' is of course understandable. But what's
the point of this extra-extra repo then? It would seem that a tool in that
repo is not 'a random tool out there'. I don't see how the extra-extra repo
would help people 'a quick way to integrate their own independent tools'.
Integrate with what, exactly?

Having three repos to put tools in and find them again is what seems awful
to me (assuming $CLANGSVN/tools is not going away), and doesn't do anything
to encourage collaboration between the multiple tool authors writing to this
list about the tools they are writing. Maybe that was never a goal though?

I could see myself writing a Makefile for the Qt 4 to Qt 5 porting tool, but
even having all the tools in one place would make it easier to maintain a
gui for all the tools outside the repo and CMake only (I'd want the tool to
offer the for loop porting, c++11 porting etc).

Thanks,

Steve.

Manuel Klimek wrote:

I think that would be a perfect fit for the "external" repository use
case.

If it's in the extra-extra repo, then it can't compile the tools from the
extra repo in. It can only invoke them through IPC. The whole point of
putting the gui together with the code would be to avoid the IPC and be able
to do more 'at once'.

The idea is to put everything that is worthy of being explicitly
re-used into clang mainline.

Eg, if the for loop refactoring tool is in the blessed extra repo and the
gui is not, then that tool can't be part of the gui.

This is an interesting point. My gut feeling would be that we could
define a plugin definition for the UI, so other people could use their
own (perhaps project specific) refactorings. Of course I might be
wrong, but that's what design discussions on cfe-dev are for :slight_smile: (with
which I mean: I'd suggest you raise this topic on how to create a
refactoring UI in an extra thread on cfe-dev, feel free to directly cc
me and chandlerc).

Cheers,
/Manuel

Manuel Klimek wrote:

Especially for the API changes we'll not be able to do that for all
tools that are out there, which I hope is understandable :slight_smile:

Not porting 'all tools out there' is of course understandable. But what's
the point of this extra-extra repo then? It would seem that a tool in that
repo is not 'a random tool out there'. I don't see how the extra-extra repo
would help people 'a quick way to integrate their own independent tools'.
Integrate with what, exactly?

Make writing a new tool:
1. click fork on github
2. checkout your project into a clang checkout, hack on it, check it
in, do all the github stuff you want to do
3. be able to point people at your project

It's mainly an entry barrier removal.

Having three repos to put tools in and find them again is what seems awful
to me (assuming $CLANGSVN/tools is not going away), and doesn't do anything
to encourage collaboration between the multiple tool authors writing to this
list about the tools they are writing. Maybe that was never a goal though?

The three repos have very clear responsiblities:
clang/tools: things that are useful for every developer using clang; libraries
clang/extra: end-user tools that don't fit into clang/tools, but
otherwise with pretty much the same requirements (style / testing /
etc) as clang/ itself; tests will be run on clang buildbots
clang/external: the build environment to easily hook into the clang
repository; this is a base for people to fork their own tool
repositories from

I could see myself writing a Makefile for the Qt 4 to Qt 5 porting tool, but
even having all the tools in one place would make it easier to maintain a
gui for all the tools outside the repo and CMake only (I'd want the tool to
offer the for loop porting, c++11 porting etc).

I expect all of the c++11 porting stuff to go into extra. For a UI,
I'm not sure, but as I said, given a good design proposal, I'm not
saying it's not going to happen :slight_smile:

Cheers,
/Manuel