Special thanks to Andrew Haley for all the fixes to the java compiler, and Xerxes Ranby who had built Eclipse on Debian for the helpful pointers.

The work involved ensuring that eclipse depedencies are built and available on my Fedora installation, creating arch specific Eclipse fragments for ARM based on the x86 fragments, a few tweaks here and there and lots of debugging of reading of ant scripts. The next step is to get the eclipse rpm building on ARM Koji.

So I wanted to speed the build up. I was under the impression that the eclipse build was IO bound so to speed that up I decided to use . I created a virtual machine with tons of memory and allocated a 4GB folder:

mkdir /tmp/build
mount -t ramfs -o size=8g ramfs /tmp/build

There was no speed up. And I had made sure that there was no swapping.

So after digging around a little bit I found a way to analyse the build better. At first I had wanted to use

iostat

but I discovered dstat.

dstat has an output which is easier to parse for graphic tools:

$ dstat -tc
----system---- ----total-cpu-usage----
     time     |usr sys idl wai hiq siq
29-11 09:34:12|  4   2  92   1   0   0
29-11 09:34:13|  4   2  91   2   1   0

The each line in the output tells it what percentage of the time since the last sample your cpu spent running user process, system process, idling, waiting for io respectively. I don’t really know what the last two values are .

So I ran:

dstat -tc >& dstat.raw

In retrospect I really did not need to sample ever second and should have run

dstat -tc 5 >& dstat.raw

to sample every 5 seconds.
So I imported dstat.raw into gnumeric and ta-da!:

The important colours above graph are the yellow (idling cpu) the blue (cpu executing eclipse build) and the turquoise (cpu waiting for io). The first thing you will notice is that there is not a lot of io blockage. Of note are the big peak in the beginning which I assume is the extraction of the sources tar ball and at the end which I assume is the writing of the rpms. The second thing you’ll notice is that there is a lot of high yellow which is evidence to the fact that my cpu’s spend most of the time idling during the build. Finally you’ll note that the blue never goes above 25% and is usually around 20%. This is because I have 4 cpu’s and the eclipse build is not parallelized.

So in conclusion eclipse build is cpu bound, and the most obvious solution to this is to make the build parallel where possible.

yum install hunspell-en

I was worried about fumbling with oddly shaped box on the subway. The cashier asked me which way I would like to carry it and stuck those handles on for me. Loved it.

I can’t prove this but I think this would work much better if the sign was on the other door saying: “Pleas use this door”

The problem still remains of course that the autotools have a high learning curve. I discussing things with Jeff Johnston (author of the current Autotools plugin in eclipse) and he had some neat ideas. His suggestion was that we create a set of wizards that will enable users to create an Autotools setup for new projects to build an executable, a static library or a shared library. This will not help people who are editing an existing makefile but will make life easier for people who are getting started. The question is are more people setting up new build systems or editing existing ones. WDYT ? And, if it is the latter how can we lower the learning curve for those developers ?

The feature I want is for ‘git status’ to show you if you are in the middle if a rebase.

I have had fun working on GDB on expression evaluation and most recently python scripting support. GDB Python scripting deserves a series of blog posts and tutorials. It enables you do do such cool things as: writing custom type printers (pretty printers), adding custom commands, and most recently (in HEAD) listening for GDB events such as a breakpoint being hit. For now, if you are interested in this I will point you to the very well written GDB Manual section 23.2.

I am excited about moving to Eclipse, and have looked forward to this move for a while. Until recently I was undecided about what to work on in eclipse. That is until I read this blog post. There is no denying that what Autotools enable us to do is awesome; configuring and building source code easily and cross-platfomly by automating the near impossible writing of makefiles to do so (… or so I have read ). The problem with Autotools is the learning curve. There is a lot that one must learn before accessing this awesomeness.

This brings me to what I would like to do with Eclipse. The problem is the learning curve, and the solution is to create an eclipse plugin which makes it ridiculously easy to write and edit Autotools scripts.

I don’t know how I’ll do it, I don’t really know if it is possible, and, to be honest, I don’t know much about Autotools. I have started by reading this book. Autotools Mythbuster was also recommended. I’ll read it next.

If you have any thoughts on this, think it is impossible, think it is possible, have recommended readings or suggestions please let me know.