[Libreoffice-qa] Minutes of ESC call: 2014-10-16

[Bjoern Michaelsen]

On Fri, Oct 17, 2014 at 11:13:12AM +0200, Jan Holesovsky wrote:
> * Open-source related projects for a local university (Jacobo)
>     + ~200-300 hours projects sought
>     + ideas appreciated!
>         + please send to the ML too :-) (Norbert)

Two ideas from the build system world:

 - 1/ Replace all custom shell tooling (sed/grep/gawk/perl horrors) and
      consolidate on either native (C/C++) code (see e.g. concat-deps) or _one_
      and only one consolidated solution beyond that, likely Python3 (as we are
      bundling that and it is a good crossplatform superset of the POSIX
      shell-world). Bootstrapping on Windows would then likely be: Install
      native Python3, execute Python script that sets up the rest.

      rationale: As we already use a native GNU make on Windows, with this we
      could remove our dependency on cygwin as Python3 is available natively on
      Windows (and all other platforms).

 - 2/ Generate native Microsoft VS Project files from the gbuild description
      for our own native C/C++ files. This:
       https://bugs.freedesktop.org/show_bug.cgi?id=70414
       https://www.youtube.com/watch?v=Xn3CtIrMpIA&hd=1
      would be the starting point.

      rationale: The aim would not be to do full release builds from these (see
      1/ about that), but should allow patching and rebuilding one specific library,
      which then can be pushed to gerrit.
      If we have this we could make the generation of these project files part
      of the Windows build and deliverables (as some kind of sdk).
      Windows people could use these to patch some libs of their version of
      LibreOffice (without a full rebuild and thus without cygwin).

2/ is the one with the more immediate payoff: I might severly lower the barrier
to entry for new contributors on Windows at least for patches with a limited
scope. With gerrit builders we have the infra in place to verify and handle
such changes without too much extra work. Of course, combined with 1/ it would
allow to ultimately move to make all Windows builds without cygwin. Which would
be all kinds of awesome for the Windows devs, I guess.

Best,

Bjoern