[LLVMdev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)
justin.holewinski at gmail.com
Thu Nov 22 08:38:29 PST 2012
On Thu, Nov 22, 2012 at 6:02 AM, Chandler Carruth <chandlerc at google.com>wrote:
> On Thu, Nov 22, 2012 at 1:53 AM, NAKAMURA Takumi <geek4civic at gmail.com>
> > 2012/11/22 Chandler Carruth <chandlerc at google.com>:
> >> Hello LLVM & Clang hackers!
> >> Based on a discussion with Chris, I would like to propose a Great
> >> Renaming of Things for the 3.3-era LLVM and Clang codebase.
> >> First and foremost, the two most significant changes I would like to
> >> 1) llvm/lib/VMCore/... -> llvm/lib/IR/...
> >> I've discussed potential names for the VMCore (or LLVMCore) library
> >> with lots of folks, and the best idea anyone has was Chris's initial
> >> suggestion: IR. So I'd like to minimize the bikeshed discussions on
> >> this one. ;]
> > Oh I missed the discussion. I prefer "Core." Yes, bikeshed.
> I dislike 'Core' and all other overly generic names. Specifically, why
> is Support not Core? Or vice versa? I would like a name that actually
> represents the principle organizing component, and that component in
> this case is the C++ APIs making up the IR of the compiler.
> >> There is one interesting question here: should we move
> >> include/llvm/*.h to include/llvm/IR/*.h to match other libraries?
> > IMHO, we may keep include/llvm/*. They should be essential interfaces.
> I dislike the inconsistency of the include tree and the lib tree. When
> that inconsistency is just collapsing an entire directory to a single
> file, it seems fine and even good when the names align. But this seems
> somewhat less principled than that.
> Essentially, consistency is a strong argument. I'm looking for strong
> arguments for keeping them where they are to counter that.
+1 for moving the IR headers into their own sub-directory. This was (is)
definitely messing with my OCD!
> > s/AsmParser/IRASM/ (to be distinguished against MCASM)
> This is a really good one.
> I would paint this bikeshed LLParser or IRParser. "Asm" has to go though.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev