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. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
