On 10/31/12 12:14 AM, Ariel Constenla-Haile wrote:
> Hi Damjan,
> 
> On Tue, Oct 30, 2012 at 07:44:06PM +0200, Damjan Jovanovic wrote:
>> Hi
>>
>> AOO is by far the biggest and most complex code I have ever hacked on,
>> and I have many questions...
> 
> true, but you managed to get your first patch out of it! Congratulations
> :) 

nothing to add here, welcome on board

> 
>> What IDE do you guys use to develop AOO? Eclipse CDT runs out of
>> memory indexing the code :-(.
> 
> I guess you cannot index the whole source tree with an IDE. It may work
> to just index the modules you are working with, no need to add all the
> dependencies, if a module depends on trunk/main/foo, simply add to the
> parser path trunk/main/foo/inc, and for the offapi/offuh header, you can
> point the parser to an SDK installation, or even point it to the solver
> include dir (but this might be too consuming). I used this approach with
> some IDEs and worked.

emacs ;-)

> 
> 
>> Many comments are in German. Are translations to English welcome or
>> should we leave them as is?
> 
> Of course they are welcome. Better if done by a native speaker or
> someone in the know (not google translate).
> 
>> Debugging is such a pain. Why do binaries get stripped when the tar.gz
>> is built even though debugging has been enabled (build debug=true
>> dbglevel=2 --all)?
> 
> they are striped when delivered to the solver. You have to configure
> with --disable-strip-solver.
> 
> I'm not sure a dbglevel=2 is good for all the modules, you will get too
> much debug output may be missing what you want to catch.
> 
> An interesting switch when developing is --enable-dbgutil that build
> a NON-PRO build http://wiki.openoffice.org/wiki/Non_Product_Build
> 

the best tool for debugging is of course MS Visual Studio. I used XCode
as well but we have first to do some work to enable XCode4.

gdb in emacs works as well but is not so comfortable like the MS Visual
Studio.

I never have tried other gdb frontends.


Juergen

>> The layout of the source code tree is incredibly complex, with eg.
>> confusing duplication of CSV parsing between binfilter/ and sc/.
> 
> binfilter is dead code, soon to be removed when trunk is in AOO4
> 
>> there somewhere I should document the structure of various modules?
>> http://wiki.openoffice.org/wiki/Source_code_directories seems like a
>> good place to start but I would add a lot more detail.
>>
>> Searching with grep takes forever. I've tried indexing the source tree
>> with Lucene, but it doesn't find everything. Is there a better tool?
> 
> Use opengrok from adfinis http://opengrok.adfinis-sygroup.org
> 
> 
> Regards
> 

Reply via email to