[ruby-core:70893] Re: How to get started with ruby-core source code development

Will Senn <[e-mail]> wrote:
> I apologize in advance if this question has been asked and answered
> before. I have scoured the internet, including this group's archives
> and have had no joy in finding the information I seek. Please be
> kind :).

Everyone has their own preferences/tools, so mine might be wildly
different from everyone elses.

I generally stick to old stuff, the lowest common denominator that's
available on any GNU/Linix system, old or new.  Anything I'm willing to
rely on, I must also be willing to debug and help fix if it goes wrong.
I do not rely on having much.

> What I would like to know is how to begin working with the ruby-core
> source code effectively. Obviously, it can be read to reasonable
> effect and understood intellectually to a large degree. I have found
> Ruby Minero Aoki's book, Ruby Hacking Guide to be helpful in this
> regard.

If you haven't already, see doc/extension.rdoc in the source
(README.EXT in older versions).

> However, I am interested in studying it with a debugger and
> this is more challenging than it sounds. I have built the source
> code on my Macbook (Yosemite), but gdb doesn't seem to work on Mac,
> and LLVM instructions are vague in the wild. I have built the 1.7.3
> source code on a debian jessie VM and used eclipse to step through
> code where I passed the path to irb into ruby as an argument and
> this "works" ok. So, with high hopes, I built the source for 2.2.3
> on the debian vm and while it built fine, it seems to be looking for
> gem files. I gather, it needs an environment variable or argument,
> so I will muddle on hoping to work past that hurdle. However, I am
> hoping someone who is actively developing the code will share their
> setup (or point me in the appropriate direction to a howto).
> 
> Specifically, what do you use to work with the code:
>     Which Operating System is hosting the ruby executable?

Various versions of Debian or CentOS GNU/Linux, occasionally
Debian GNU/kFreeBSD or FreeBSD

>     Are there environment parameters that need to be set or passed
> as arguments?

Nothing besides an extra element in PATH ($HOME/r-whatever/bin)
where I used ./configure --prefix=... (see below).

>     What Tools are useful (eclipse, gdb, valgrind, etc)?

I use (exuberant-)ctags in day-to-day with almost-stock vim.
git commands: "git grep", "git log -p"  if I'm lucky enough
to have a git repo + installation available.

I use gdb for inspecting core dumps, only.
valgrind if I'm actively hunting a memory leak.

Often I'll find a well-placed "fprintf(stderr, ...)" is enough for
figuring out what's going on.  strace helps, as does combining
it with:

	write(-1, "..."); errno = 0;

If you can't take too much output on stderr or are inside a signal
handler or a small thread stack where you can't *printf.

Sometimes I'll write a short functions with the GCC
__attribute__((constructor)) / __attribute__((destructor))
attributes to dump out accumulated stats and such.

ccache is helpful for speeding up builds since I could be
branches frequently and cause make to repeat too much work.

None of this is specific to Ruby, by the way...


Writing a test extension (see test/-ext/* for examples) helps,
too.

I definitely do not use Eclipse (or any GUI tools) as I only work with
command-line interfaces.  Relying on a GUI would mean I'd potentially
get dragged into debugging a constantly-changing GUI stack or worse:
graphics drivers with poor, one-off specs and documentation and/or
unfixable proprietary blobs.  Life's too short for that.

I already get dragged into enough projects (ruby-core included)
because I kept finding bugs or ways to improve through normal use.

>     How do you keep a pristine working environment for your work, chroot?

./configure --prefix=$HOME/r-whatever/  for day-to-day with my
usual user account.  This works for anything using autoconf or
similar, so it's applicable to a lot of projects.

Sometimes I might use a different user account + home directory
if I want to test something more experimental/unsafe or likely
to leave a mess.

Then even more occasionally I'll use a chroot (if there's a larger
dependency such as glibc change) or KVM if there's a kernel dependency.

>     Any helpful hints on editing  a c file, rerunning make, running
> gdb and info func myfunc, etc. would be tremendously helpful.

I edit + make + and do whatever relevant tests in a loop until I'm
satisfied with the result.