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

On Nov 24, 2012, at 1:02 AM, Tinco Andringa <mail at tinco.nl> wrote:
> Hi,
> 
> I think it's an awesome idea to make sure all names are logical. It is
> an essential feature of a good API to have logical naming :)
> 
>> I really dislike that all the files and classes in the MC library
>> start with MC. This is c++, not c :(
> 
> On a similar note, all the classes in clang/CodeGen are prefixed with
> CG or even CodeGen, could those be renamed as well?
Yes.  For example, CodeGenFunction would become IRGenFunction.
CGCall.cpp would become... probably either GenCall.cpp or IRGenCall.cpp,
with my preference being the shortest that's still unambiguous
throughout the project, which I think means Gen*.
> And speaking of the clang codegenerator, I as a llvm newbie was
> confused by the ModuleBuilder.h/.cpp. These files actually contain the
> definition of the CodeGenerator itself that I was searching for (being
> sort of the entry point of the codegenerator).
> 
> I think it would be more clear if they were called
> CodeGenerator.h/.cpp. Or perhaps even splitted out into
> CodeGenerator.h and IR/CodeGenerator.h/.cpp.
This is really just a historical accident, and I have no objections to fixing
it.

John.

Hi there.

What about repainting the top-level bike-shed - the build system itself?

I've got a framework called "v3c" in SourceForge that has a
top-level
makefile.
 From that makefile you can just do "make" to build it with debug 
information,
"make release" for a release build,
"make -j7 distcheck" to throw a few cores at the build,
"make -j7 git branch=a.b.c release debian" to checkout version a.b.c
to
a separate directory and build a debian package with it.

I've got several projects in SourceForge that "inherit" this 
functionality, and some (like v3c-storyboard) use several of them at once.

This would end the notion of "in-tree" components - projects become 
"derived" from llvm, like clang.

I don't know if it's even possible to try one version of clang with a 
different version of llvm, or whether that even makes sense, but this 
way, you can if you want to.

Then there's doxygen integration - providing you set up things 
consistently, your AnOther project inherits the doxygen tag files from 
the projects it inherits from.

So, in the case of v3c-storyboard, it inherits the documentation from 
v3c, treedb, meta-treedb, v3c-dcom, cxxparse and v3c-qt, which 
integrates Qt's doxygen documentation.

Plus the build flags of the parent projects are available for reuse in 
client projects.

It's all automake/pkg-config/git based but I hope it can serve as a 
point of reference - what my bike-shed looks like.

A bike-shed too far?

Regards,
Philip Ashmore

On Tue, Nov 27, 2012 at 4:40 PM, Philip Ashmore
<contact at philipashmore.com>wrote:
> Hi there.
>
> What about repainting the top-level bike-shed - the build system itself?
>
>
Offtopic for this thread. Please start a new one if you'd like to discuss
this.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20121127/c3be414a/attachment.html>

On 28/11/12 00:40, Philip Ashmore wrote:
> Hi there.
>
> What about repainting the top-level bike-shed - the build system itself?
>
> I've got a framework called "v3c" in SourceForge that has a
top-level
> makefile.
> From that makefile you can just do "make" to build it with debug 
> information,
> "make release" for a release build,
> "make -j7 distcheck" to throw a few cores at the build,
> "make -j7 git branch=a.b.c release debian" to checkout version
a.b.c
> to a separate directory and build a debian package with it.
>
> I've got several projects in SourceForge that "inherit" this 
> functionality, and some (like v3c-storyboard) use several of them at 
> once.
>
> This would end the notion of "in-tree" components - projects
become
> "derived" from llvm, like clang.
>
> I don't know if it's even possible to try one version of clang with
a
> different version of llvm, or whether that even makes sense, but this 
> way, you can if you want to.
>
> Then there's doxygen integration - providing you set up things 
> consistently, your AnOther project inherits the doxygen tag files from 
> the projects it inherits from.
>
> So, in the case of v3c-storyboard, it inherits the documentation from 
> v3c, treedb, meta-treedb, v3c-dcom, cxxparse and v3c-qt, which 
> integrates Qt's doxygen documentation.
>
> Plus the build flags of the parent projects are available for reuse in 
> client projects.
>
> It's all automake/pkg-config/git based but I hope it can serve as a 
> point of reference - what my bike-shed looks like.
>
> A bike-shed too far?
>
> Regards,
> Philip Ashmore
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev