Sean: I agree with many of your points, but I don't agree that we have to address them all beforehand. Some of them we don't even know just yet. But I have started up the documentation and will update that with as much information as I have.
Chandler: ping? On Wed, Jun 5, 2013 at 8:15 PM, Sean Silva <[email protected]> wrote: > > Some really high-level thoughs: > > One thing that I think has been neglected in the development of our > other tools is what the end-user experience looks like. I feel like a bit > of high-level "this is what I want the user experience/workflow to feel > like" iteration at this stage could really have a significant payoff down > the road. (side note: I love how clang-format is so easy to use, but it > really has it easy since it doesn't need to fully parse and build AST's; > clang-tidy has it a lot harder) > > By "user experience/workflow" I mean a holistic end-to-end use case for > the tool (such as our own, i.e. dogfooding). Especially: > > * which commands they run to actually do stuff with the tool (and I > don't mean in isolation; I mean a sequence of commands starting with `git > clone`/`svn co`) > * what an external user's code would look like (where in their > repository would they store extra checks of their own? how does this tie in > with their build system? how to deal with backwards compatibility?). > > I think we should have a clear vision of how we are going to dogfood > this before committing any code, because honestly, if we don't use this, > how can we expect others to? A couple questions off the top of my head: > > * How is this going to integrate with our build system? > * Are we going to have pre-commit hooks? or a bot that automatically > replies to patches on the mailing list/phabricator with issues flagged by > clang-tidy? > * Is this something that a handful of people run periodically in > batches, or is this something that we expect all developers to run on their > code before committing? > * What fraction of our checks are idiosyncratic, and how many are > generic and usable by other projects? > > For example, I think it makes sense for llvm-specific checks to live in > the LLVM source tree (*not* clang-tools-extra); e.g. our idiosyncratic > include ordering. Then we get to feel what this actually feels like for an > external project. Of course, as many have said, it makes a lot of sense to > have a bunch of generally useful non-idiosyncratic checks that others can > readily call upon in a config file, but we really need to consider > idiosyncratic checks (i.e. C++ code using these APIs that is maintained in > an external source tree). > > Maybe we should build a pretotype (if you aren't familiar with that word > you can ignore this sentence)? We have excellent technical implementation > ability, so TBH actually building the tool isn't the hard part: we really > ought to make sure we are building "the right it" before "building it > right". > > http://llvm-reviews.chandlerc.com/D884 >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
