[Gluster-devel] Tips and Tricks for Gluster Developer

[Joseph Fernandes]

----- Original Message -----
From: "Jeff Darcy" <jdarcy at redhat.com>
To: "Richard Wareing" <rwareing at fb.com>
Cc: "Gluster Devel" <gluster-devel at gluster.org>
Sent: Monday, January 25, 2016 7:27:20 PM
Subject: Re: [Gluster-devel] Tips and Tricks for Gluster Developer

Oh boy, here we go.  ;)

I second Richard's suggestion to use cscope or some equivalent.  It's a good idea in general, but especially with a codebase as large and complex as Gluster's.  I literally wouldn't be able to do my job without it.  I also have a set of bash/zsh aliases that will regenerate the cscope database after any git action, so I rarely have to do it myself.

JOE : Well cscope and vim is good enough but a good IDE (with its own search and cscope integrated) will also help.
I have been using codelite (http://codelite.org/) for over 2 years now and it rocks!


Another secondary tip is that in many cases anything you see in the code as "xyz_t" is actually "struct _xyz" so you can save a bit of time (in vim) with ":ta _xyz" instead of going through the meaningless typedef.  Unfortunately we're not as consistent as we should be about this convention, but it mostly works.  Some day I'll figure out the vim macro syntax enough to create a proper macro and binding for this shortcut.

I should probably write a whole new blog post about gdb stuff.  Here's one I wrote a while ago:

http://pl.atyp.us/hekafs.org/index.php/2013/02/gdb-macros-for-glusterfs/

There's a lot more that could be done in this area.  For example, adding loc_t or inode_t or fd_t would all be good exercises.

On a more controversial note, I am opposed to the practice of doing "make install" on anything other than a transient VM/container.  I've seen too many patches that were broken because they relied on "leftovers" in someone's source directory or elsewhere on the system from previous installs.  On my test systems, I always build and install actual RPMs, to make sure new files are properly incorporated in to the configure/rpm system.  One of these days I'll set it up so the test system even does a "git clone" (instead of rsync) from my real source tree to catch un-checked-in files as well.

I'll probably think of more later, and will update here as I do.


_______________________________________________
Gluster-devel mailing list
Gluster-devel at gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel