In the interests of breaking up the commits for the migration tool, I have prepared a skeleton for the executable, tests, and one of the transformations. This should give us a concrete example to work with, along with a place for me to commit changes as they begin to work reliably.<div>
<br></div><div>Thoughts?</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jul 2, 2012 at 9:37 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On Jul 2, 2012, at 11:25 AM, Douglas Gregor wrote:<br>
> Similarly for the migration tools. Most users want to migrate to C++11, or migrate to modern Objective-C. The languages are different enough that it doesn't seem we'd benefit much from having one tool capable of migrating to modern Objective-ARC++11 in one shot… although you're wearing me down on that particular issue. A code "modernizer" that covers the various languages doesn't fall afoul of my justification below...<br>

<br>
</div>I'm assuming that this will eventually grow to include more than just a few modernizers...<br>
<div class="im"><br>
>> What is the downside of having all the rewriters be in the same tool?<br>
><br>
> That tool has no obvious purpose or scope; it's just a grab bag of rewriters that happened to land in the tree. That's very hard to communicate to potential users. It also doesn't fit well with the tooling model, which intends to make it easier to build one-off, specialized tools, which are likely to be easier to use than a single executable with a pile of command-line options.<br>

><br>
> I do also worry about quality: it's far easier to qualify and test a specialized tool than it is to test all of the emergent combinations from an overly-general tool, especially if the robustness of various pieces varies wildly (which I expect it will). IIRC, the ARC migrator and ObjC modernizer needed some massaging to make all of the rewrites play nicely together, and that's a fairly small set of rules written by a very small number of people.<br>

<br>
</div>Ok, I'm not going to fight strongly for this. :)  If you guys think that it makes sense to keep them all separate, that's cool with me.  If it turns out to be a bad idea in the future, they can always be merged at that point.<br>

<span class="HOEnZb"><font color="#888888"><br>
-Chris<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>