From dev-return-63868-archive-asf-public=cust-asf.ponee.io@openoffice.apache.org Fri Oct 5 20:45:56 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 398C8180649 for ; Fri, 5 Oct 2018 20:45:55 +0200 (CEST) Received: (qmail 11965 invoked by uid 500); 5 Oct 2018 18:45:54 -0000 Mailing-List: contact dev-help@openoffice.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openoffice.apache.org Delivered-To: mailing list dev@openoffice.apache.org Received: (qmail 11952 invoked by uid 99); 5 Oct 2018 18:45:53 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Oct 2018 18:45:53 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 22F6CC00DB for ; Fri, 5 Oct 2018 18:45:53 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 1.89 X-Spam-Level: * X-Spam-Status: No, score=1.89 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, KAM_SHORT=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id jNfz00CqHmIh for ; Fri, 5 Oct 2018 18:45:50 +0000 (UTC) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id ED3DF5F24A for ; Fri, 5 Oct 2018 18:45:49 +0000 (UTC) Received: by mail-wm1-f48.google.com with SMTP id s12-v6so2744337wmc.0 for ; Fri, 05 Oct 2018 11:45:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=oo2gaLttuZHo1MeA8MQ+oFmX1TXFS4fYmUbm+1ms/bg=; b=YbH5FM/TE9b0UsoGLDBNe1dw8vptBgJteIxRre2OavttfouiNXgQbl57lv+NTp3yPb Xz8L87NISYfqWH/J6MxvKG2NBEoIZwahkR3jA1MjkTtWL0uSckURdO/Iee8joO1qUsGU Q/e3Gl/nuEQ8rqerPKrnVDyunszkljoghsqtIUH8IKLBZ35I2WtVJx3YrOzhM8e79Qrk otQxi5Y4H5hoT7/38Yt1Wf/l8Sj8GRBbCf7SdF8hauus+QYnmtuqO0Gicot1frWMU9mE imReT+Tgz1kXW+FdFkhYSUgsK8kZtBsan/cGsLamkymiV9JiHPV+ZFMOtMFBWPaYOC5h kKBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=oo2gaLttuZHo1MeA8MQ+oFmX1TXFS4fYmUbm+1ms/bg=; b=bMqUnoIVWTvbfFyWkv7AjKbq98FJAD3X/6cnEcFUtVFcgm7LMKlYyLSWP8Fd1OUZBH jVskV3BcVQO3U7OLYZthjkBibXFdRZnil5AaG6YY3M/MCleVeXi0jDdO7+oJqjzZULIq anetd2xt5U+YoZJRkxtZlWG00OEv9l0Cbt6ppsyu5uup3xAcEsJnfOHr31boVdpP1Nr5 iTwr/3oVXFTAr1QzxG9J/e2su715bTYcq4Ml8i33gADOnA2vOlvZrNgv8wP6RWRV/oFJ J8KJTIB5+UBVOCjC9CW+rPOgCjKD82HM9U2iZh5SHd819Psdqzry4IXqyNTG3wJ0QbhQ e+NA== X-Gm-Message-State: ABuFfojEFKq7J/S0Qc6jK0veCrf28Geu2xbO1vh6nr993zv8QPNkxN8d QXf+hYu883mH4hyUNQUffIxG12/m X-Google-Smtp-Source: ACcGV60g3NPKY5yza63IGHJGQUJLArt++3jxkY2vzWDroGvqkAKmASR+8zshCnLHnL/u7O0viP0nyg== X-Received: by 2002:a1c:8181:: with SMTP id c123-v6mr8316989wmd.3.1538765142750; Fri, 05 Oct 2018 11:45:42 -0700 (PDT) Received: from [192.168.1.12] (athedsl-226301.home.otenet.gr. [85.74.203.155]) by smtp.gmail.com with ESMTPSA id l16-v6sm1539827wmc.38.2018.10.05.11.45.41 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Oct 2018 11:45:41 -0700 (PDT) From: George Karalis Content-Type: multipart/alternative; boundary="Apple-Mail=_5FF35F32-8024-48D1-85E8-F454FD57A7BE" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Subject: Re: Other build ideas (was: Re: Windows Build Environment futures Date: Fri, 5 Oct 2018 21:45:39 +0300 References: <3451572b-7a30-c26c-6365-66067c5c6d6d@Apache.org> To: dev@openoffice.apache.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3445.100.39) --Apple-Mail=_5FF35F32-8024-48D1-85E8-F454FD57A7BE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello everyone, Since am new to the project and working on understanding the build = process this past week, I agree with Damjan that the build system needs that overhaul. I = also agree that a MSVC upgrade and a 64-bit windows build, is of high priority. Changing = the build=20 system will take months. As of the MSVC upgrade I have figured out how the whole configure works = and I =E2=80=98m now integrating MSVC++ 14.15 to oowintool script, and trying to = integrate Windows 10 SDK to the configure pipeline as well. After that I 'll try to figure = out the build errors and fix everything to a successful build. If and when the upgrade completes, = we should also investigate implementing targets - if there are none - for the build = tool. e.g. To compile for windows XP, we need the Windows XP platform toolset, = which installs Windows 7.1 SDK, among other things and can build for Windows XP using = MSCV++ 2017 and run something like: build =E2=80=94all =E2=80=94target=3D=E2=80=9C= winXP=E2=80=9D. Since I am unfamiliar with UNO, I can=E2=80=99t provide any points = there, but I agree with that separation of concerns, to keep only office functionality at the core of = the project. Also another future idea would be to split - I don=E2=80=99t know if it's = possible - each application, Writer, Calc, Impress etc. in its own separate module, so they can build = independently=20 and, maybe?, debug easier, since someone can work on features on only = the app he/she wants. As for the build system, after some research, I concluded on three = modern build pipelines, CMake, SCons and Meson. Personally, I am in favour of CMake, with the = only argument that it=E2=80=99s backed by many large companies and that provides a = safety for the future. The two=20 systems are almost identical, SCons is more extensible due to Python, = but all in all it=E2=80=99s just a weight of each build system's pros and cons. Also, = how KDE switched=C2=A0 to CMake was an interesting read. = But, I think Damjan knows better about the project, so we can have an open discussion about which build system is better for = OpenOffice. I think that for now we should focus on upgrading our tools, new = compilers, SDKs, because it's easier, it has been a week and I have done some progress already, = and it will ease=20 development a little, but ultimately changing to a modern build system = can have tremendous=20 potential for the project, modern build systems integrate perfect with = Visual Studio, Xcode, working on an IDE it=E2=80=99s always nice =F0=9F=99=82. Kind regards, George > On 5 Oct 2018, at 20:32, Damjan Jovanovic wrote: >=20 > The split wouldn't help us with newer MSVC as such. >=20 > What would help us there a lot, is SCons, as SCons supports many MSVC > versions already, including MSVC 2017. It would be so wonderful if we = were > on SCons already: not only would we build with a wider range of MSVC > versions, but we would need less work to keep up with future MSVC = versions. > But unfortunately I think it's a lot easier to move to a new MSVC, = than it > is to move to SCons. Especially given how heavy build development and > testing would be necessary on all platforms, and we don't have a Mac = or > OS/2 or Solaris setup available... >=20 > On Fri, Oct 5, 2018 at 6:38 PM Peter Kovacs wrote: >=20 >> Hi Damjan, >>=20 >> I o not understand the MSVC part. If we separate UNO it's own world. >> (Independent of the Idea to spin it of into its own project) >>=20 >> will the update of the MSVC be easier? >>=20 >>=20 >> All the best >>=20 >> Peter >>=20 >>=20 >> On 10/5/18 10:15 AM, Damjan Jovanovic wrote: >>> Hi >>>=20 >>> I now have a few other ideas regarding the building story. >>>=20 >>> The gbuild migration has been extraordinarily long and painful. = Sadly >> I've >>> had to learn so much about gbuild, and implement so many new = features in >> it >>> (symlinks, UNO IDL, Ant, bison, flex, now assembly...), that I am = getting >>> good at it now :(. A lot of what I've done would have to be = reimplemented >>> on SCons. But there are advantages to redoing stuff in SCons: for >> example, >>> we could run code in Python instead of calling external tools like = awk, >> tr >>> and sed, and thus gain more portability, reduce dependencies, and = ditch >>> Cygwin. >>>=20 >>> However I consider SCons lower priority than a 64 bit Windows build, = and >> a >>> newer MSVC (especially given our MSVC version is now unavailable!). >>>=20 >>> Also one of the things that's made work on all of those projects >> difficult >>> is the sheer size of AOO, the number and diversity of modules. One = of my >>> ideas is to split up AOO into 2 layers: an UNO layer at the bottom, = and >> an >>> office layer at the top. This is something that's been in the = pipeline >> from >>> the OOo days, and at one stage I think OOo was distributed with a >> separate >>> UNO installation, and there's even a file in main/ure/source/README = that >>> describes how the split would be done. These layers would be in = separate >>> directories, along the lines of ext_sources/, main/ and test/ now, = and >>> would build separately: first UNO, then office. >>>=20 >>> How does this help? Changes can be contained. Different build = systems >> could >>> be experimented with, for each. A Win64 bit UNO could be developed = and >>> tested before we begin porting office modules to Win64. Ultimately, = UNO >> is >>> a general framework for cross-platform multi-language = component-based >>> development, similar to Microsoft's COM and Mozilla's XPCOM, and I = think >> it >>> should be a completely separate project, that is hosted, developed, = and >>> packaged independently of AOO (eg. http://uno.apache.org), and is a >> just a >>> compile-time and run-time dependency for us, that we download, use, = and >>> ship just like zlib and libjpeg. >>>=20 >>> I really think the world needs a cross-platform multi-language >>> component-based framework. Microsoft's COM is Windows-only, and = Mozilla >> is >>> gradually getting rid of XPCOM. There are few other implementations, = and >> we >>> have what seems to be the only permissively licensed one, and the = only >> one >>> supporting exception handling between different languages (I think = both >> COM >>> and XPCOM don't support exceptions and require return codes; the = infamous >>> HRESULT with its bitfields). >>>=20 >>> Almost all the UNO modules are using gbuild already (it's mostly = office >>> that is troublesome and does lots of custom things during the build = :-), >> so >>> a 100% gbuild UNO can be split off soon, and UNO can then = potentially >> start >>> using SCons, a newer MSVC, and/or producing a Win64 build, before = office >>> even finishes the gbuild migration. >>>=20 >>> There is some work involved. We would have to split up configure.ac, >>> duplicate some of the build scripts, somehow deliver UNO files into = the >>> office build. Quite a few of the office prj/build.lst would have to >> change >>> to not depend on the modules that move. Nothing would initially = improve; >>> only after other changes could dependencies be reduced. Not needing >> Cygwin >>> requires both UNO and office to use SCons, a Win64 office also = requires >>> both. The biggest initial benefit might be that since UNO doesn't = change >>> often, rebuilding would be faster, as only office modules would = rebuild. >>> And the office source code tree would be smaller and clearer. >>>=20 >>> On the downside, the same version of MSVC must compile both UNO and >> office, >>> as C++ symbols from different MSVC versions are incompatible. This = pretty >>> much means we have to build UNO from source inside office. >>>=20 >>> Anyway, what do you think? >>>=20 >>> Damjan >>>=20 >>>=20 >>> On Sun, Sep 23, 2018 at 10:46 AM Peter Kovacs = wrote: >>>=20 >>>> At the same time, the migration from Windows 32bit Version to = support >>>> 64bit has been started. The build currently breaks somewhere. A >>>> continuation would be awesome. >>>>=20 >>>> And we are moving the build environment from dmake to gmake. There = are >>>> 65 modules left. This activity has a huge impact because all = platforms >>>> are effected. And according to Damjan, the low fruits have been = already >>>> migrated, and the ones left are not easy. >>>>=20 >>>> @Damjan, you still would like to migrate then to SCON after gmake, = btw? >>>> I would still like to, even I do not count my voice much, because I = did >>>> not drive this topic much. :( >>>>=20 >>>>=20 >>=20 >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org >> For additional commands, e-mail: dev-help@openoffice.apache.org >>=20 >>=20 --Apple-Mail=_5FF35F32-8024-48D1-85E8-F454FD57A7BE--