llvm dev - Nov 2012 - [LLVMdev] [cfe-dev] RFC: A Great Renaming of Things (or: Let's Repaint ALL the Bikesheds!)

On 11/22/12 04:53 PM, NAKAMURA Takumi wrote:
> 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
make:
>>
>> 1) llvm/lib/VMCore/... ->  llvm/lib/IR/...
(-1 karma to self for participating in bikeshed)

I'm not sure how and if this change would affect my group, but I'd have 
a slight preference to llvm/lib/LLVMIR/
-----------
While the current naming may not be the best I'm -1 for the change in 
general.

On Thu, Nov 22, 2012 at 2:49 AM, "C. Bergström"
<cbergstrom at pathscale.com> wrote:
> On 11/22/12 04:53 PM, NAKAMURA Takumi wrote:
>>
>> 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
>>> make:
>>>
>>> 1) llvm/lib/VMCore/... ->  llvm/lib/IR/...
>
> (-1 karma to self for participating in bikeshed)
>
> I'm not sure how and if this change would affect my group, but I'd
have a
> slight preference to llvm/lib/LLVMIR/
I'm pretty opposed to repeating LLVM in the name of any directory...
There's absolutely no ambiguity here.
> While the current naming may not be the best I'm -1 for the change in
> general.
Are there any serious reasons or concerns? I'm well aware that this
will impose a cost on out-of-tree projects, but on the whole it should
be pretty minimal and consist of some applications of 'sed'.

On 11/22/2012 12:07 PM, Chandler Carruth wrote:
>> While the current naming may not be the best I'm -1 for the change
in
>> > general.
> Are there any serious reasons or concerns? I'm well aware that this
> will impose a cost on out-of-tree projects, but on the whole it should
> be pretty minimal and consist of some applications of 'sed'.
Well, it's a bit more serious than that if an out-of-tree project tries
to support older LLVM versions (e.g., Pure still supports all LLVM
versions >= 2.5). Alas, most popular Linux distributions still package
old LLVM versions (e.g., Ubuntu 12.04 LTS has LLVM 2.9, and this will
still be around for a long time). That's something we poor out-of-tree
projects just have to live with if we don't want to tell our users to
compile their own LLVM from source.

I've learned how to live with the frequent C++ API changes, but in any
case it would be nice if these name changes are documented meticulously
so that 3.3 doesn't become a veritable nightmare for 3rd party projects. ;-)

Albert

-- 
Dr. Albert Gr"af
Dept. of Music-Informatics, University of Mainz, Germany
Email:  Dr.Graef at t-online.de, ag at muwiinfa.geschichte.uni-mainz.de
WWW:    http://www.musikinformatik.uni-mainz.de/ag

Chandler Carruth wrote:
> Are there any serious reasons or concerns? I'm well aware that this
> will impose a cost on out-of-tree projects, but on the whole it should
> be pretty minimal and consist of some applications of 'sed'.
It would be a good practice to attach the sed commands to all renaming commits.

Thanks,
Sebastian
-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The
Linux Foundation