Re: make gbuildtojson and make xx-ide-integration problems.

Hi,

On Thu, Dec 15, 2016 at 02:58:29PM +0100, Markus Mohrhard wrote:
> 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.

Agreed.

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

Yup.

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

Yes, but also plumbing whatever build button there is in an IDE to call make is
trivial. The non-trivial part is with LibreOffice -- because of its size -- the
strategy of 'eh, lets just build everything all of the time' is somewhat more
painful than for trivial projects. While it is the safe default for newcomers,
regulars usually dont want to spent their time triggering full build everytime.
This problem (that we have all 'module build', 'full build', 'unitcheck',
'slowcheck', 'subsequentcheck' being useful and needed build scenarios) wont go
away by any tweaks in IDEs and or using any build system. There simply cant be
a one-size-fits-all button in the IDE for this.

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

Yes, and since, as you so eloquently pointed out, setup is still the most
tricky part of this -- at least on Windows -- I wonder if the solution is
possibly rather to double down on having properly preconfigured VMs with IDE,
debugging and code completion available and ready to spin up at a minutes
notice ...

Best,

Bjoern