From dev-return-63872-archive-asf-public=cust-asf.ponee.io@openoffice.apache.org Sat Oct 6 07:20:28 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 936B318061A for ; Sat, 6 Oct 2018 07:20:27 +0200 (CEST) Received: (qmail 59337 invoked by uid 500); 6 Oct 2018 05:20:26 -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 59316 invoked by uid 99); 6 Oct 2018 05:20:26 -0000 Received: from mail-relay.apache.org (HELO mailrelay2-lw-us.apache.org) (207.244.88.137) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Oct 2018 05:20:26 +0000 Received: from mail-oi1-f174.google.com (mail-oi1-f174.google.com [209.85.167.174]) by mailrelay2-lw-us.apache.org (ASF Mail Server at mailrelay2-lw-us.apache.org) with ESMTPSA id 2F9A9469 for ; Sat, 6 Oct 2018 05:20:25 +0000 (UTC) Received: by mail-oi1-f174.google.com with SMTP id j68-v6so12061629oib.7 for ; Fri, 05 Oct 2018 22:20:25 -0700 (PDT) X-Gm-Message-State: ABuFfojLBma7CI6LIZbWhSHwcSW1uiYKsgRxO7xlq0or84J3NI+Z9Ta/ kZnVgPSu2VaYhBDNxpBj9/nGnI97HzvcpjmFJ9o= X-Google-Smtp-Source: ACcGV61DcBKjBdwe2nIq2gunovV6KxhTGIy1WFHqLagmPNpjlTy4LGiNytVn/WsOjtO1DrlTxCAbYa1DncdI8Zh/BFo= X-Received: by 2002:aca:af4a:: with SMTP id y71-v6mr940737oie.274.1538803224379; Fri, 05 Oct 2018 22:20:24 -0700 (PDT) MIME-Version: 1.0 References: <3451572b-7a30-c26c-6365-66067c5c6d6d@Apache.org> <8990f51b-ba3a-bf5c-b6b5-cd1bf66ab817@Apache.org> In-Reply-To: From: Damjan Jovanovic Date: Sat, 6 Oct 2018 07:18:19 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Other build ideas To: Apache OO Content-Type: multipart/alternative; boundary="0000000000009187820577888b76" --0000000000009187820577888b76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Those links are in the wrong category then. They refer to OOo not the ODF Toolkit. On Sat, Oct 6, 2018 at 3:54 AM Dave Fisher wrote: > > > Sent from my iPhone > > > On Oct 5, 2018, at 6:37 PM, Damjan Jovanovic wrote: > > > > 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 wi= ll likely > retire. It might end up with TDF. > > > > > Let's leave the split for now. It's not going to help us directly. > > Agreed. > > Regards, > Dave > > > >> On Fri, Oct 5, 2018 at 11:59 PM Peter Kovacs wrote: > >> > >> Hi all, > >> > >> I am a bit skeptical about the 2 Layer approach. OpenOffice has been > >> designed in a 3 Layer Architecture. This can be seen here. > >> > >> https://wiki.openoffice.org/wiki/File:ArchOverview.jpg > >> > >> As this documentation states the Lower Layer does not only consists of > >> the UNO Group but also of UCB, ConfigManager, GSL. > >> > >> 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. > >> > >> > >> 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. > >> > >> We can do a Spinoff maybe later, I like the Idea in general to have so= me > >> of the Contrsucts that make OpenOffice so awesome offer to other > >> Projects in order to get people with different goals to colaborate. > >> > >> our BASIC Language is also such a topic. But I think this are lower > >> priorities with the project power we currently have. > >> > >> > >> Damjan, George do you see any Issues with my plan or would you prefer > >> the initial Idea? > >> > >> > >> Thanks guys for the thoughts. They are really good IMHO. > >> > >>> On 10/5/18 8:45 PM, George Karalis wrote: > >>> 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 > >>> system will take months. > >>> > >>> As of the MSVC upgrade I have figured out how the whole configure wor= ks > >> 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 usin= g > >> MSCV++ > >>> 2017 and run something like: build =E2=80=94all =E2=80=94target=3D=E2= =80=9CwinXP=E2=80=9D. > >>> > >>> Since I am unfamiliar with UNO, I can=E2=80=99t provide any points th= ere, 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 > >>> 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 > >>> 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 > >>> 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 > >>> development a little, but ultimately changing to a modern build syste= m > >> can have tremendous > >>> potential for the project, modern build systems integrate perfect wit= h > >> 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: > >>>> > >>>> The split wouldn't help us with newer MSVC as such. > >>>> > >>>> What would help us there a lot, is SCons, as SCons supports many MSV= C > >>>> versions already, including MSVC 2017. It would be so wonderful if w= e > >> 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 an= d > >>>> testing would be necessary on all platforms, and we don't have a Mac > or > >>>> OS/2 or Solaris setup available... > >>>> > >>>>> On Fri, Oct 5, 2018 at 6:38 PM Peter Kovacs > wrote: > >>>>> > >>>>> Hi Damjan, > >>>>> > >>>>> 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) > >>>>> > >>>>> will the update of the MSVC be easier? > >>>>> > >>>>> > >>>>> All the best > >>>>> > >>>>> Peter > >>>>> > >>>>> > >>>>>> On 10/5/18 10:15 AM, Damjan Jovanovic wrote: > >>>>>> Hi > >>>>>> > >>>>>> I now have a few other ideas regarding the building story. > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> However I consider SCons lower priority than a 64 bit Windows buil= d, > >> and > >>>>> a > >>>>>> newer MSVC (especially given our MSVC version is now unavailable!)= . > >>>>>> > >>>>>> 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/READM= E > >> 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. > >>>>>> > >>>>>> 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. > >>>>>> > >>>>>> 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 implementation= s, > >> 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). > >>>>>> > >>>>>> Almost all the UNO modules are using gbuild already (it's mostly > >> office > >>>>>> that is troublesome and does lots of custom things during the buil= d > >> :-), > >>>>> 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. > >>>>>> > >>>>>> There is some work involved. We would have to split up configure.a= c > , > >>>>>> duplicate some of the build scripts, somehow deliver UNO files int= o > >> the > >>>>>> office build. Quite a few of the office prj/build.lst would have t= o > >>>>> change > >>>>>> to not depend on the modules that move. Nothing would initially > >> improve; > >>>>>> only after other changes could dependencies be reduced. Not needin= g > >>>>> 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. > >>>>>> > >>>>>> On the downside, the same version of MSVC must compile both UNO an= d > >>>>> office, > >>>>>> as C++ symbols from different MSVC versions are incompatible. This > >> pretty > >>>>>> much means we have to build UNO from source inside office. > >>>>>> > >>>>>> Anyway, what do you think? > >>>>>> > >>>>>> Damjan > >>>>>> > >>>>>> > >>>>>> On Sun, Sep 23, 2018 at 10:46 AM Peter Kovacs > >> wrote: > >>>>>> > >>>>>>> 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. > >>>>>>> > >>>>>>> And we are moving the build environment from dmake to gmake. Ther= e > >> 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. > >>>>>>> > >>>>>>> @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. :( > >>>>>>> > >>>>>>> > >>>>> -------------------------------------------------------------------= -- > >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org > >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org > >>>>> > >>>>> > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org > >> For additional commands, e-mail: dev-help@openoffice.apache.org > >> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org > For additional commands, e-mail: dev-help@openoffice.apache.org > > --0000000000009187820577888b76--