I had some free time yesterday so I thought I’d try to dabble in building Fennec with some debugging to figure out why it looks like ass on my phone. I’ve played with building Fennec a few times before and like everytime before the first thing I needed to do was fix the problems in the build system that breaks building for Android from OSX. Everyone else uses a Linux host it seems. This time there were only two bugs to be found and on the off chance anyone else is trying to do this I thought I’d link to them.
The first problem is that the library search path is a little broken in one place. On Linux it works because when make looks for libz.so it finds it in the linux libraries, on OSX it doesn’t (only libz.dylib exists). I came up with a hacky solution but it turns out Patrick has what looks to be a much better fix in bug 639568.
The second problem is in libvpx. I guess some of the asm code needs to know the offsets of certain structures in the object files generated from the C code. There is a little tool built which looks into the object files and outputs the offsets. Since it is a build for ARM the object files are in elf format, but when this tool is built on an OSX host it is built to look in MachO object files. The fix in bug 641267 is quite hacky but does the job at least. It just forces the tool to build for elf support and has to include an elf.h since OSX does not come with one. I probably need to figure out how to file this upstream to get a better solution but for now I can build which is all I need.
Of course you can’t even start building without an NDK for OSX. Fennec builds with a customised version of the NDK based on the CrystaX NDK but with the queue.h header added. Mozilla have a version for Linux on the ftp site but I had to put together my own for OSX. It’s available to download if you need it, I’ll see if we can just get it added to the ftp site too.
Hopefully this is useful to others, sadly by the time I had figured out how to get my build working I had run out of spare time to actually work on my problem
Update: It seems that even these fixes aren’t quite enough. Although this gets the build to complete it crashes on startup on my phone. Then again my attempts to build on Linux also crash shortly after startup on my phone so maybe I have other problems.
Firefox 4 is just around the corner and it’s great to look back over just how far the Add-ons Manager has come since Firefox 3.6. In fact if you want to see the full history look at my earlier post that shows its evolution since Phoenix 0.2. We set out with some pretty lofty goals for Firefox 4 and I’m pretty excited at just how many of them we achieved. I hope everyone appreciates the hard work that Blair, Boriss, Justin, Henrik, Ben, myself and all the others put in to get us to where we are today.
Of course, we aren’t finished. There were a lot of things that we wanted to get done and didn’t get time for and I’m sure we’ll be getting lots of feedback from users of the final release to work on. Since the pressure has been off I’ve been skimming back over bug reports and notes to try to come up with an idea of what we want to work on over the next few releases of Firefox. As you may know the plan is to move to quarterly releases and not really block a release on any particular projects but we will still be getting an idea of what product drivers will prioritise work on and guess at what other things we can fit in.
In the closing stages of Firefox 4 there were a lot of small polish issues identified. We knocked down a lot of them but there are still plenty of tweaks that we’re going to be bringing to the UI to make sure it is as usable as we can make it. It isn’t really worth applying a fixed schedule to these as they are small one-off fixes that can just come as and when ready. We already have some that are basically ready to land.
Incremental API fixes
There are lots of things that I’d like to see done for the platform and APIs that developers use. Again there is no fixed schedule for these but the main things on my mind are changes that make developing restartless add-ons or extending the add-ons manager easier. I’ve already started work on a couple of these and expect to get them landed after the tree reopens.
There are of course also larger projects that will require more resources. I’ve started writing up short project pages for each of these. Each project should start with the people working on it coming to agreement on what the actual goals should be and an implementation plan so until the projects are actually picked up the project pages are mostly made up. I’ve put down a rough idea of when a project might make it into a Firefox release. These are just guesses, if the project turns out to be larger than expected they’ll come later, if people volunteer to work on projects or if the product drivers decide they are a priority then they could come sooner.
You can see that assuming a quarterly release schedule we have enough projects here to last till the end of 2011 at least, quite likely longer. Over that sort of time I guess it’s almost guaranteed that priorities and plans will change in the meantime but hopefully this gives an idea of what our thinking is at the moment. Expect to see progress on some of the things at the top of the list very soon!