Re: gbuildtojson

Hi,

On Mon, Dec 05, 2016 at 10:52:36PM +0100, jan iversen wrote:
> well last time I tried it in windows java and python was not included. Also
> there was a lot of targets missing.

Well, Python/Java are ~7% of LOC in LibreOffice core repo, and less then 2%(?)
of the shipped core product. The latter is thankfully sinking: The only place
were new non-C++ code is acceptable in the core repo is non-shipped testcode
(for shipped C++ code).

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

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

So:
1/ LibreOffice core development (in C++) as described above is already covered
   by existing solutions.
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].
3/ Mixing these two is ill-advised -- and that has little to do with the build
   system. As said, the only place for non-C++ code in the core repo is for
   testcode testing C++ implementations. If you are debugging a C++/Python or
   C++/Java mix talking over an UNO bridge, setting breakpoints in an IDE will
   be the least of your problems[2].

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

So again: What usecase that isnt covered by existing solutions are you looking
for?

Best,

Bjoern


[1] Note that for this (non-core development), my talk at FOSDEM provided good
    hints and a proof of concept on how to get LibreOffice extension
    development going with PyDev, including breakpoints etc.:
    http://people.canonical.com/~bjoern/presentations/snakes.odp
    But again: This has nothing to do with core development!

[2] From a TDD perspective, if your test coverage is fine-grained enough, you
    will never need a debugger, because your tests makes obvious where your code
    is wrong, without stepping through things interactively or breakpoints. For
    me, the is the only reason to allow new non-C++ testcode in core. A test
    that still needs breakpoints and interactive stepping, you are indeed better
    served with C++ tests.

[3] One day the day may come that we want/need to replace gbuild with something
    different. Once that day is there, we will have to migrate to whatever
    replaces it as swiftly as possible (which will be, given the size of the
    project, still be very slow, even though gbuildtojson and the cleanup that
    happened when we introduced gbuild will make it a lot easier than it was to
    get away from dmake). But before a/ there is a clear need to kill gbuild
    and b/ there is a build system that promises to cover the whole core build,
    this is not an option. In other words: A new build system must be able to
    completely kill and replace gbuild, and be worth the effort.

    Gbuild could pull off that trick -- not because it was such a masterpiece of
    engineering -- it isnt. It was only worth it because dmake was such a pain.

    That said, GNU make is a small -- and by now native -- dependency on all
    platforms. Cygwin as a dependency on Windows is a much bigger risk and
    painpoint. I suspect, if anything, that will be killed first.