make gbuildtojson and make xx-ide-integration problems.

[Markus Mohrhard]

Hey,

so with the experience of writing one of the ide integrations and helping
people especially during the night some comments.

On Thu, Dec 15, 2016 at 1:33 PM, Bjoern Michaelsen <
bjoern.michaelsen at canonical.com> wrote:

> Hi,
>
> On Thu, Dec 15, 2016 at 01:02:05PM +0100, Jan Iversen wrote:
> > since you have already made the ball rolling by making gbuildtojson in
> C++
> > the logical consequence would be to port the script to C++.
>
> My fear with that was it (using C++ instead of Python) would discourage
> people
> to contribute for other IDEs. But now that we have at least a wireframe
> implementation for most popular IDEs going straight to C++ might indeed be
> our
> best option[1] bootstrapping-wise. Although parsing JSON in C++ is rather
> ...
> meh, but we certainly dont want an external dependency for that.
>
> Probably needs an iterative approach: first parse the JSON stuff in some
> C++
> objects and create output for the first IDE. Other IDEs move over from
> Python
> to C++ one by one later.
>
>

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.


Also a few comments for the general discussion.

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


Regards,
Markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20161215/d4c4875b/attachment.html>