On Thu, Mar 17, 2016 at 1:09 AM, Patricia Shanahan <p...@acm.org> wrote:
>
>
> On 3/16/2016 12:07 PM, Damjan Jovanovic wrote:
>
>> On Wed, Mar 16, 2016 at 8:49 PM, Patricia Shanahan <p...@acm.org> wrote:
>>
>>
>>>
>>> On 3/16/2016 11:24 AM, Damjan Jovanovic wrote:
>>>
>>> On Wed, Mar 16, 2016 at 8:18 PM, Patricia Shanahan <p...@acm.org> wrote:
>>>>
>>>> On 3/14/2016 10:49 AM, Oliver Brinzing wrote:
>>>>
>>>>>
>>>>> Hi Patricia,
>>>>>
>>>>>>
>>>>>> Has anyone nailed getting e.g. windbg running with AOO on Windows? If
>>>>>> so,
>>>>>>
>>>>>> I have some questions.
>>>>>>>
>>>>>>>
>>>>>>> better try with vs 2013 community edition 😉
>>>>>> I remember I had a lot of trouble with windbg.
>>>>>>
>>>>>>
>>>>>> Thanks for the tip - it does work better than windbg.
>>>>>
>>>>> However, I seem to have a problem with it not loading all the symbols,
>>>>> so
>>>>> I cannot set a breakpoint where I want.
>>>>>
>>>>> My general procedure is to build AOO with configure parameter
>>>>> --enable-symbols. I unzip the archive version, copy soffice.bin, and
>>>>> rename
>>>>> the copy sofficebin.exe.
>>>>>
>>>>> In Visual Studio, I do File-Open-Project/Solution and select my
>>>>> sofficebin.exe. It seems to do some symbol loading, but not the module
>>>>> I
>>>>> want.
>>>>>
>>>>> Anyone have any suggestions?
>>>>>
>>>>>
>>>>> Which module are you trying to debug this way? --enable-symbols only
>>>>>
>>>> seems
>>>> to work for dmake modules, gbuild modules don't get any debug symbols. I
>>>> have a preliminary fix.
>>>>
>>>>
>>> I was trying to debug in main/tools/source/generic.
>>>
>>>
>> main/tools uses gbuild, so it won't have debug symbols with
>> --enable-symbols.
>>
>> As a workaround, after "source winenv.set.sh", "cd" to "tools", and run
>> "make clean debug=true" to rebuild it with debug symbols. Then "build
>> --all" from instsetoo_native to pull in that debug copy when building the
>> new installation package, or (much faster especially on Windows) if you
>> know which files it built, you can copy those yourself from solver/420/...
>> over the ones in your pre-existing AOO installation.
>>
>>
> This workaround works, but I keep needing to apply it to additional
> modules, which makes debug slow. Is there a list, or a quick way of
> identifying, the gbuild modules so I can just remake them all?
>
> Thanks,
>
> Patricia
>
>
This may sound strange coming from someone that's been merging 132 gbuild
patches between branches in the last few weeks, but I am not sure what the
definitive list is:
* main/Module_ooo.mk seems to list every gbuild module, but sd is not
there, and is a gbuild module on my branch...
* gbuild modules usually have an empty <module>/prj/d.lst, but AOO builds
when it's not empty
* gbuild modules usually have a 2 line <module>/prj/build.lst
* gbuild modules usually have a <module>/prj/makefile.mk, which usually
calls $(GNUMAKE) with various options. Since $(GNUMAKE) is needed to launch
the gbuild makefiles, it is a robust check, but it could theoretically be
launched from any file specified in <module>/prj/build.lst...
* gbuild modules usually have a <module>/Makefile
The <module>/Makefile should be easiest for now ("ls main/*/Makefile").
Damjan
