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

[nicholas ferguson]

(1)  A LibreOffice is not sanely built from Visual Studio.  just too big. It
overloads eclipse. A python + MSBuild, as an initial build, download of tar
files...anything divorced from cygwin is a better idea.
	1.1  It's present build system, after study and understanding of
what build path to take...does run smoothly and does recover when build
threads crash.  Divorce it  from cygwin and keep that smoothness would be
great.
(2)  If VStudio is to be used, then a VStudio solution file for SCALC, and a
separate one for Word, or Visio... Each would load up all of its
dependencies and any associated env initialization files ( ala cppunit
test).  That could work.  Though.. a combination of python scripts for
builds and Visual Studio will probably be used in conjunction ...by windows
develoeprs...similar to using cygwin shells scripts and visual studio.
	2.1  Any developer would be concentrating on one of those modules,
anyway.




-----Original Message-----
From: LibreOffice [mailto:libreoffice-bounces at lists.freedesktop.org] On
Behalf Of Bjoern Michaelsen
Sent: Friday, October 17, 2014 2:29 PM
To: Jan Holesovsky
Cc: Libreoffice-qa; libreoffice-dev
Subject: Re: [Libreoffice-qa] Minutes of ESC call: 2014-10-16

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