From dev-return-63871-archive-asf-public=cust-asf.ponee.io@openoffice.apache.org Sat Oct 6 03:54:06 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 6B144180649 for ; Sat, 6 Oct 2018 03:54:05 +0200 (CEST) Received: (qmail 50147 invoked by uid 500); 6 Oct 2018 01:54:04 -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 50128 invoked by uid 99); 6 Oct 2018 01:54:03 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Oct 2018 01:54:03 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id D8B1E183E15 for ; Sat, 6 Oct 2018 01:54:02 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KAM_ASCII_DIVIDERS=0.8, KAM_SHORT=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=disabled Authentication-Results: spamd3-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id xXLnRNDlMk-a for ; Sat, 6 Oct 2018 01:54:00 +0000 (UTC) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [96.114.154.160]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id EB8235F16F for ; Sat, 6 Oct 2018 01:53:59 +0000 (UTC) Received: from resomta-po-16v.sys.comcast.net ([96.114.154.240]) by resqmta-po-01v.sys.comcast.net with ESMTP id 8bgMgcr5jbeAp8bmzgcU0M; Sat, 06 Oct 2018 01:53:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1538790833; bh=YtQBLNmOSRmzok9Z+bXCb0rL9YGqdOYfHGL+EpsVWF0=; h=Received:Received:From:Content-Type:Mime-Version:Date:Subject: Message-Id:To; b=OSaQuphpJWUf3Wr9Z25rumjGJn/0/q2I5B0JADn12WSKFBn8kl/bqpTbzqMOQXX2r 5jNr87/mu6sBRPbcr5PnMcwYlA+UiWqhMY0+EG7FDjzxPWCgJwxbcKzs5P2/k44l5g 3OLAUgULTqNrU7VU/5UHHO0heP5Y2Si/cy7grEbHzp63J0IH8Vi/RnPAIv1fWqgaAB AJ4RPoIovb4yNvKRNT2FNETNqpemOL5tP0/Fl0eErn/w3oJONhvTup1XkAFGkyhkRt MzrYTC1kNR3V1iPwnOhNlgeyIGqpqjfI9ug2O8FOp3yf2WXrqYvKHgUAU3XZNOZMAF NKjg7bllSvOlw== Received: from [IPv6:2601:649:101:8656:818b:7332:924c:7c02] ([IPv6:2601:649:101:8656:818b:7332:924c:7c02]) by resomta-po-16v.sys.comcast.net with ESMTPA id 8bmxgWvnjk4KV8bmygUwYI; Sat, 06 Oct 2018 01:53:53 +0000 From: Dave Fisher Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Fri, 5 Oct 2018 18:53:51 -0700 Subject: Re: Other build ideas Message-Id: References: <3451572b-7a30-c26c-6365-66067c5c6d6d@Apache.org> <8990f51b-ba3a-bf5c-b6b5-cd1bf66ab817@Apache.org> In-Reply-To: To: dev@openoffice.apache.org X-Mailer: iPhone Mail (16A366) X-CMAE-Envelope: MS4wfA+dUp9wCf4XXroxqwE6q2iiPzZA2PCgtddbxjpIYUO1D6Db97oKELK899wf0bQp36c6VPYlG2KYwHMiPwHzBO5wMvkIjG/lSK/kSCBOKCMGe1UgrF/V 9MM46liLoJuIwibgodZxis3B/3a78a3VboKrLutKNYVNPSeC8bQLtrGUTt82CqsBTqmm5fFHKsfrmaH9PDnQiQNK9uQkdhkM2wkI7E9/+xHChRGulb4xzRx3 RIM4KHbEctEU9LDmrHHj7TmJmypuSqQVILH3WquYJTgZ53e5Os/nGrH7UmKVn4Sq Sent from my iPhone > On Oct 5, 2018, at 6:37 PM, Damjan Jovanovic wrote: >=20 > The links you are looking for are: > https://wiki.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE > https://wiki.openoffice.org/wiki/ODF_Toolkit/Efforts/Three-Layer_OOo ODF Toolkit is still in the Incubator. It=E2=80=99s just Svante and it will l= ikely retire. It might end up with TDF. >=20 > Let's leave the split for now. It's not going to help us directly. Agreed. Regards, Dave >=20 >> On Fri, Oct 5, 2018 at 11:59 PM Peter Kovacs wrote: >>=20 >> Hi all, >>=20 >> I am a bit skeptical about the 2 Layer approach. OpenOffice has been >> designed in a 3 Layer Architecture. This can be seen here. >>=20 >> https://wiki.openoffice.org/wiki/File:ArchOverview.jpg >>=20 >> As this documentation states the Lower Layer does not only consists of >> the UNO Group but also of UCB, ConfigManager, GSL. >>=20 >> I do prefer actually to maybe build a containment along these "old" >> Layers instead of cutting UNO out. I hope it causes less refactoring work= . >>=20 >>=20 >> Of course we would not be able do start a UNO - SpinOff Project right >> away, but we would get similar advantages, with maybe less work. >>=20 >> We can do a Spinoff maybe later, I like the Idea in general to have some >> of the Contrsucts that make OpenOffice so awesome offer to other >> Projects in order to get people with different goals to colaborate. >>=20 >> our BASIC Language is also such a topic. But I think this are lower >> priorities with the project power we currently have. >>=20 >>=20 >> Damjan, George do you see any Issues with my plan or would you prefer >> the initial Idea? >>=20 >>=20 >> Thanks guys for the thoughts. They are really good IMHO. >>=20 >>> On 10/5/18 8:45 PM, George Karalis wrote: >>> Hello everyone, >>>=20 >>> 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 >>> system will take months. >>>=20 >>> 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. >>>=20 >>> 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= =9CwinXP=E2=80=9D. >>>=20 >>> 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 pos= sible - >> each application, >>> Writer, Calc, Impress etc. in its own separate module, so they can build= >> independently >>> and, maybe?, debug easier, since someone can work on features on only >> the app he/she >>> wants. >>>=20 >>> 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 saf= ety for >> the future. The two >>> 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, h= ow KDE >> switched >>> 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. >>>=20 >>> 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 >>> development a little, but ultimately changing to a modern build system >> can have tremendous >>> 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. >>>=20 >>> Kind regards, >>> George >>>=20 >>>=20 >>>> 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 pipelin= e >>>>> 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, an= d >>>>>> 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 an= d >>>>>> 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 onl= y >>>>> 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 suppor= t >>>>>>> 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 >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org >>>>>=20 >>>>>=20 >>>=20 >>=20 >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org >> For additional commands, e-mail: dev-help@openoffice.apache.org >>=20 >>=20 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org For additional commands, e-mail: dev-help@openoffice.apache.org