Re: gbuildtojson

> 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.