Mostly Web and Mozilla related content
Over the last year I've been working on-and-off with one of the Eclipse CDT developers, Andrew Gvozdev, to resolve the issues preventing Eclipse from being really useful for Mozilla C++ development. I'm pleased to say that, mainly as a result of Andrew's hard work, the latest release candidate of the next version of Eclipse is now much easier to set up with Mozilla, and it's now possible to get the code assistance features working a whole lot better (and without jumping through the ugly, unreliable hoops that were previously required). I'm personally finding the ability to quickly find all the callers of a method, dig up/down through call hierarchies, find all overrides, browse inheritance trees, refactor, etc. to be hugely beneficial in my C++ development work. If you're a Mozilla C++ dev you should give it a try, and hopefully it will similarly boosts your productivity and ability to grok unfamiliar parts of the source.
Oh, and yes, Bas, it does understand nsCOMPtr. ;-)
Rather than provide setup instructions here on my blog, I've completely rewritten the old Eclipse page on MDC and replaced it with an Eclipse CDT wiki page. If you're interested, head over there and find out how to get started. If you have any issues with or questions about that documentation, feel free to comment below, or to email me or catch me on IRC.
I want to say a big thank you to Andrew Gvozdev. It's Andrew's SD90 project to completely rewrite Eclipse CDT's old and badly broken build output parser that finally got Eclipse's code assistance working well with Mozilla. Andrew was very quick to fix bugs and integrate feedback over the last year, despite probably secretly wishing at times that I'd give his Inbox a rest. Thanks, Andrew, you rock!! :-)
Oh, and if you find any bugs or rough edges in Eclipse CDT, I'm sure Andrew and the other CDT folks would love you to file CDT bug reports (CC me if you do).
Tags: Mozilla, Eclipse, C++
Archived comments
Benoit Girard
This is great news, thanks for the hard work! I'll be trying this out soon.
I had tried it a few months ago and it worked fine except that auto complete would hang eclipse which made it slower to use than even vanilla vim.
11 June, 2012 at 15:24
Jonathan Watt
From my experience, if Eclipse hangs, it's usually because its memory limits need to be increased - see the wiki page for details on that. (There was also Eclipse bug 379337 which I filed and which got fixed -- whenever it encountered an '#import' line on Mac, it would go into an infinite memory allocation loop until it ran out.)
Anyway, if you follow the steps on the wiki hopefully you'll find its code assistance features work a lot better than "fine". :-)
11 June, 2012 at 15:43
Vince
I followed the instructions at MDN using Eclipse Juno, here are a few observations:
-> "Add a recursive, regular expression "Exclude all" filter for files with Name matching "\.(?:rej|orig|o|pp|swp)$" to exclude .rej, .orig, .pp, .o and .swp files." & "Click OK to close the filters window, wait for Eclipse to finish processing your resource filters, then make sure the filtered directories and files have disappeared from the Project Explorer tab on the left." ---- tried numerous times, but files matching the expression are still in the Project Explorer, for example I can still see .o files when I expand the object directory. Incidentally, after closing the filters window, sometimes Eclipse is stuck refreshing /media/webrtc/trunk/tools/gyp/test/mac/sourceless-module, sometimes it just finishes refreshing workspace immediately, but I'm not sure if it's related to the Explorer filter failure.
-> Building the project using just-print-mozilla-build.py works, but there are 2 errors reported in the "Problems" tab:
https://pastebin.com/wVMKCrfj
There's no path nor location specified in the problem details, it just says "C/C++ Problem".
-> The number of unresolved includes is 1,568 :-( Curiously, when I use Eclipse SDK 4.2.1 with CDT installed, the number is higher - at 1,809. I tried adding all features present in C/C++ IDE to the SDK, but the result is still the same. I'm not sure where this difference comes from.
1 February, 2013 at 19:53
Jonathan Watt
I'm not sure of the cause of the filter and errors in the "Problems" tab. I don't have either issue. Regarding changes in the number of unresolved includes, I've observed things like that but didn't dig into that particular issue.
1 February, 2013 at 21:36
Jens
... fails for me:
20 May, 2013 at 23:49
Jonathan Watt
It looks like you missed out the '...delete the word "all" from the...' step.
21 May, 2013 at 01:37
Franz
Good morning,
I followed the instruction but when it comes to launch just-print-mozilla-build.py through the builld command, it seems to hang and remains stucked at 18% (??)
There is no significant output on the console :
but python is still using some CPU cycles.
The first build done outside Eclipse was made for Thunderbird only (ie ac_add_options --enable-mail) and serialized (-j1 -w). Could this be part of the problem ?
Any idea what is happening ?
Regards, Franz
7 December, 2013 at 10:43
Jonathan Watt
The fact that your initial build was serialized should not be an issue. As far as I know, you're the first person to try the Eclipse CDT instructions with --enable-mail though. It's possible that you may have discovered a mail specific issue.
That said, there are issues that the wiki page needs to be updated for. The mozilla build system has been changing to use unified builds, which breaks build option discovery in Eclipse CDT. To get around this you'll need to temporarily add the following line to your .mozconfig file when invoking the build option discovery build from Eclipse CDT (or have a separate .mozconfig file for this purpose):
There's also the issue that support for building using 'make' is going to be dropped at some point, and is not necessarily fully supported even now. Instead of invoking make, I need to update just-print-mozilla-build.py to invoke mach (or better yet integrate just-print-mozilla-build.py into mach), but there is some trickiness that I don't have time for right now.
I'd suggest that until I can find time to update the instructions and scripts that you don't use just-print-mozilla-build.py. All it does is make CDT build discovery builds fast, but since it's broken it's a waste of your time. Instead make CDT invoke |./mach build| (mach is a script in the root of the mozilla source directory) and in addition to adding the --disable-unified-compilation option temporarily add this line to you .mozconfig:
Run |./mach clobber| from the command line, then build from inside CDT. Since this is a full -j1 clobber build without unified builds it will take a loooong time, but once CDT has the build options you shouldn't need to update them for a month or two, by which time I should have sorted out the scripts and wiki page.
7 December, 2013 at 10:43