On 12/17/13 9:58 AM, Andre Fischer wrote: > Hi, > > About a week or so ago I tried again to import the OpenOffice source > code into Eclipse. The last time I tried that, a few years ago, this > did not work at all. Our source code was just to big and too complex. > This time however, it worked out of the box. If you do it right :-) > The developers of the CDT (the C/C++ Development Tooling) have made > great progress in the last years. > > As this allows newcomers a much easier way to become OpenOffice > developers and also can make the work of experienced developers more > productive I would like to share how to set up Eclipse for OpenOffice. > This process is still a bit rough around the edges. Any help is > appreciated. > > I have started a Wiki page [1] which explains the manual setup. It > should work on all platforms but at the moment only Windows is > described. Maybe you can help to fill in missing values for other > platforms. I am working on a few Eclipse plugins to automate this process: > > - A wizard for setting up an Eclipse workspace. The prototype has just > to be pointed to the (compiled) source code. It will then collect all > the necessary include paths and set the necessary compiler defines so > that the indexer can resolve even the platform dependent definitions. > This is important because even something as simple as sal_Int16 will not > be recognized without the indexer being told about platform specific > preprocessor defines. > > - The idea of CDT about how C/C++ files are built is different from how > OpenOffice does it. Therefore I am developing a short term solution > that provides a couple of buttons/menu entries/whatever will be > appropriate to build the current module, directory or file and then > deploy the new libraries into an installed office. > > > Here are some highlight of what Eclipse and CDT allow us to do: > > - Easily switch between header and implementation file. > > - Follow header inclusion (just Ctrl-click on an #include statement and > the referenced header file is opened in the editor. > > - Get information about variables and classes by simply hovering over > their names. A popup box shows you the variable definition or the class > implementation. That is something you have to see to believe it. > > - Find out from where a function or method is called > > - Explore the type hierarchy of a class. > > - Macro expansion. Hover over a macro use and see the expansion of it, > several iterations if necessary. Ever wanted to know how IMPL_LINK is > defined? Just move your mouse pointer over it. > > - Code assist while typing. Define a variable, eg. > ::rtl::OUString sText > Then type "sText.", wait a little (default is 500ms) and a box shows > you all the available methods of OUString. > > - An overview at the right side shows you all the functions, methods, > includes, macro defines etc, that are made in the currently edited > file. Click on one and jump to the corresponding source code. > > > All of this may sound familiar to Java developers. But for C++, > especially for OpenOffice, I think this is quite remarkable.
And to underline what Andre has described above, this is really cool and we are sure it will help us a lot. I watched a video from Bjoern Michaelsen from LO where he presented something similar for KDevelop and pointed out what's possible with their new complete gbuild system .... I didn't understand the relation between the build system and the integration and talked with Andre about and others about it. Andre who is quite familiar with Eclipse (I am more a NetBeans guy) spend a first hour on experimenting with Eclipse. We didn't knew that and after an hour he presented us the first results which were impressive. I did a similar test on my Mac with the same result and was able to compile and debug (old gcc env) in Eclipse. Well I had some problems with the new upcoming env (clang, lldb) because there is no lldb tool chain for Eclipse yet. But anyway the whole support and the advantage of the indexer and the related navigation in the source code is so huge that we will definitely continue and follow up on this. And as Andre pointed out this is and can be fun and even the results after a few hours were impressive. If there are volunteers who have experience in plugin development for Eclipse please join and help us to make this even more comfortable. OpenOffice developers please try it out and I am sure you will be impressed and it will help you a lot to find your way in the OpenOffice code jungle. This will hopefully help to attract some new developers in the future. gdb debugging should work in Eclipse, Xcode and of course MS Dev Studio has great debugging features but the editing and navigating in Eclipse is quite nice and really useful. And keep in mind that we had the first results after 1 hr. Ok the details and to make it more generic requires more time. Eclipse is for sure not the only IDE where stuff like this is possible but one advantage is that it is platform independent which is perfect for OpenOffice. But of course something similar on Windows in MS Dev Studio would be probably even more comfortable and I am looking forward to the outcome the ongoing project to build the whole of office with MS Dev. Try it out Juergen > > > Best regards, > Andre > > > [1] https://wiki.openoffice.org/wiki/OpenOffice_and_Eclipse > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
