> Well, Python/Java are ~7% of LOC in LibreOffice core repo, and less then 2%(?)
> of the shipped core product.
But if I want to make an executable within the IDE, or debug e.g. some of the
unit test I still need it.
One of the hard points for new people is actually to be able to debug unit
tests.
>> The simple use case, of being able to develop/build/debug within the
>> IDE....especially debugging is important. setting breakpoints on the lines
>> and viewing variables is what students learn todo.
>
> Thats already possible with existing IDE integrations.
At least not in the Xcode integration.
for a couple of reasons (which might apply to windows as well, will test that
later):
- the debugger cannot run, it has not main executable.
- make and Xcode puts objects in different places.
- Also it is important to see the relationship between modules (especially when
searching for symbols).
>> Students want to do all development within the IDE, and I do not see why it
>> should be impossible.
>
> "All development within the IDE" (including breakpoints and debugging) is
> already
> the status quo.
>
I might be doing something wrong, but I have until and including today, not
being able to 1/ set a breakpoint 2/ press debug 3/ stop at the breakpoint,
neither in windows nor in Xcode.
> 1/ LibreOffice core development (in C++) as described above is already covered
> by existing solutions.
See above, right now the Xcode-ide-integration has another problem:
Jans-iMac:work jani$ make xcode-ide-integration
make -j 8 -rs -f /Volumes/LIBREOFFICE/play/core/Makefile.gbuild gbuildtojson
cd /Volumes/LIBREOFFICE/play/core &&
/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide --ide xcode --make make
Traceback (most recent call last):
File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 1651, in
<module>
gbuildparser = GbuildParser(args.makecmd).parse()
File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 180, in parse
lib = self.__lib_from_json(json.load(f))
File "/Volumes/LIBREOFFICE/play/core/bin/gbuild-to-ide", line 131, in
__lib_from_json
GbuildParser.libpattern.match(os.path.basename(json['MAKEFILE'])).group(1),
AttributeError: 'NoneType' object has no attribute 'group'
Makefile:413: recipe for target 'xcode-ide-integration' failed
make: *** [xcode-ide-integration] Error 1
which I will investigate and patch.
> 2/ Python/Java non-core development support is somewhat lacking. But the
> solution there is not fiddling around with gbuild -- rather rewriting the
> LibreOffice SDK (http://api.libreoffice.org/docs/install.html) and make it
> trivial to install and use. C++ isnt a priority for that[1].
We should not be fiddling with the gbuild system, I never suggested that.
But you forget that we have many unit tests written in Java and python, which
we ask new people to debug when they have problems.
> Also note for 1/ we really, really only want _one_ build system. The _current_
> plethora of build configurations and platforms is already an major factor in
> slowing down development and we really, really dont want to want to add more
> "diversity" or TIMTOWTDI there[3].
I politely disagree here. we have 1 master build system and that is gbuild, but
I cannot see anything hindering, that we use the ONE build system, to generate
e.g. a IDE build system.
I never suggested, and will not suggest to have a second build system as master.
> So again: What usecase that isnt covered by existing solutions are you looking
> for?
Simply put, to be able to debug in the IDE, make simple changes, run again and
see the effect, which I still have not been able to do.
rgds
jan i.
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
