<div dir="ltr"><div>Hey,<br><br></div>so with the experience of writing one of the ide integrations and helping people especially during the night some comments.<br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 15, 2016 at 1:33 PM, Bjoern Michaelsen <span dir="ltr"><<a href="mailto:bjoern.michaelsen@canonical.com" target="_blank">bjoern.michaelsen@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<span class=""><br>
On Thu, Dec 15, 2016 at 01:02:05PM +0100, Jan Iversen wrote:<br>
> since you have already made the ball rolling by making gbuildtojson in C++<br>
> the logical consequence would be to port the script to C++.<br>
<br>
</span>My fear with that was it (using C++ instead of Python) would discourage people<br>
to contribute for other IDEs. But now that we have at least a wireframe<br>
implementation for most popular IDEs going straight to C++ might indeed be our<br>
best option[1] bootstrapping-wise. Although parsing JSON in C++ is rather ...<br>
meh, but we certainly dont want an external dependency for that.<br>
<br>
Probably needs an iterative approach: first parse the JSON stuff in some C++<br>
objects and create output for the first IDE. Other IDEs move over from Python<br>
to C++ one by one later.<br>
<br></blockquote></div><br><br></div><div class="gmail_extra">I'm not really sure if switching to C++ will really help us long term. It might solve the python3 problem on OSX short term but would make hacking the IDE generator quite painful. Actually at least I don't see huge problem with letting the script depend on the python that we use for the build, whether internal or external, and therefore just build the python on OSX when we run the script. At least for the case that we pre-generate IDE solutions (which is what I read to make it apparently possible for really everyone to open a LibreOffice source file) I think it would not be an issue. And for anyone who actually still would use the command line to build LibreOffice it should make even less of a difference.<br><br><br></div><div class="gmail_extra">Also a few comments for the general discussion.<br><br>In general my experience from mentoring people and helping out during the European night is that at least currently our problem is not really the missing IDE integration. At least from what I can see currently the two big problems that we have are some unreliable tests, e.g. the OpenCL ones, and the brittle setup on windows. So I think focusing on these two issues for now would help new people much more. Additionally I don't believe that we will ever be able to cover every single part of the LibreOffice build process in an IDE so it might make more sense to use the IDE integration for the normal C++ source file hacking and leave the rest to make, so basically going with the old 80/20 rule. If the build would be less brittle, mostly on windows, calling make once should not be such a big problem. Actually at least I would most likely not want to mentor a person that considers calling make once in a command line a reason not to contribute to the project.<br></div><div class="gmail_extra">Besides that I see a problem with having a second way of building LibreOffice especially from the mentoring perspective. We already have the huge problem that experienced developers often don't use the setup that we suggest to new developers. Increasing the difference between these groups would make the mentoring even more complicated. From this perspective a reliable and well tested IDE integration that supports the common task, hacking the source files with auto completion and maybe debugging of LibreOffice and tests, without the additional complexity of a complete build in the IDE seems like a less painful solution. It surely would be easier to maintain and support people using such an IDE integration.<br><br><br></div><div class="gmail_extra">Regards,<br></div><div class="gmail_extra">Markus<br></div><div class="gmail_extra"><br><br><br><br></div></div>