[clang-tools-extra] r187428 - cpp11-migrate: Write header replacements to disk
chandlerc at google.com
Tue Jul 30 15:26:11 PDT 2013
On Tue, Jul 30, 2013 at 1:48 PM, Vane, Edwin <edwin.vane at intel.com> wrote:
> > From: Alex Rosenberg [mailto:alexr at leftfield.org]
> > Sent: Tuesday, July 30, 2013 4:31 PM
> > To: Vane, Edwin
> > Cc: Tareq A. Siraj; cfe-commits at cs.uiuc.edu
> > Subject: Re: [clang-tools-extra] r187428 - cpp11-migrate: Write header
> > replacements to disk
> > YAML was included as a serialization format to be used only for
> > testing tools, not as a supported output format. In fact, we discussed
> > the role of YAMLTraits in order to support some of our actually used
> > formats like plists to support generic logic in serialization.
> I'm not sure how the original intention for YAML is relevant to the
> situation. We're making using of existing functionality in LLVM to simplify
> a problem.
> > I'm pretty strongly against this direction.
> Why exactly?
> > I know of exactly zero tools that use YAML as a format for
> We don't want to target existing tools. One new tool exists so far:
> https://github.com/revane/migmerge_git which is a prototype for a more
> powerful tool we'll soon be building. These output files are not meant for
> consumption by external tools (unless of course somebody wants to build
> such a tool). They serve only as an intermediate format for data flowing
> from >>1 C++11 Migrator processes to 1 Migration Post-Processor process via
> the filesystem. Inter-process communication would be nice but it's not
> easily portable.
> I've CC'd Manuel who, I think, is familiar with how Google solves this
> problem internally with protocol buffers. I believe he suggested YAML but
> we didn't exactly discuss the issue in detail. He might have something to
> add from his experience.
So, you didn't CC Manuel, and Manuel wasn't involved in the original
Most of the problem here is that the original discussion was buried in a
patch review thread that didn't really give any indication that there was a
significant design decision being made here which would require review from
a wider audience. I'm not sure the best way to achieve that, but I have
1) Don't start with a patch, start with just a sketch of a design. Doesn't
have to be formal, and should be very brief.
2) Send the email to cfe-dev@ and put 'RFC' or something in the title.
3) Directly CC people you want design feedback from. I think Manuel is
Anyways, Alex seems to raise an interesting design question. I don't
actually have an opinion on it (haven't thought about it much), but I
wanted to try to improve the process here as I suspect that lots of others
will have thoughts on this subject within the community. A reply to a
commit mail is the wrong place to have a detailed discussion about the
design. cfe-dev@ is better.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits