From dev-return-63874-archive-asf-public=cust-asf.ponee.io@openoffice.apache.org Sat Oct 6 11:40:21 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 B2DA1180677 for ; Sat, 6 Oct 2018 11:40:20 +0200 (CEST) Received: (qmail 49805 invoked by uid 500); 6 Oct 2018 09:40:14 -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 49794 invoked by uid 99); 6 Oct 2018 09:40:14 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 06 Oct 2018 09:40:14 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 427781A09E6 for ; Sat, 6 Oct 2018 09:40:14 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.527 X-Spam-Level: X-Spam-Status: No, score=-0.527 tagged_above=-999 required=6.31 tests=[KAM_ASCII_DIVIDERS=0.8, KAM_SHORT=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.972] autolearn=disabled Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id A_Qeu64gL_J0 for ; Sat, 6 Oct 2018 09:40:10 +0000 (UTC) Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.141]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 25CAD5F2F0 for ; Sat, 6 Oct 2018 09:40:10 +0000 (UTC) Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 1D52920F17 for ; Sat, 6 Oct 2018 11:40:03 +0200 (CEST) Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 42S1nG42FHz6tmH for ; Sat, 6 Oct 2018 11:40:02 +0200 (CEST) Subject: Re: Other build ideas To: dev@openoffice.apache.org References: <3451572b-7a30-c26c-6365-66067c5c6d6d@Apache.org> <8990f51b-ba3a-bf5c-b6b5-cd1bf66ab817@Apache.org> From: Peter Kovacs Organization: Open Office Project Message-ID: <83eb2fc5-e10f-3399-1d78-0c140afa0355@Apache.org> Date: Sat, 6 Oct 2018 11:40:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US-large At first glance it looks like it wants what we want, but on second glance it describes the removal of UNO from OpenOffice, and divide the Monolithic package we have into 3 packages along the layers. I think it is what Libre Office has already done. But for sure it will give hints on the issues we might face. The Idea is to reuse old Architecture design for the SCon and MSVC migration, but stay in the monolithic package. It is more a move towards a stronger and better inner architecture, with the goal to be better able to do maintenance. I do really prefer your Idea on creating an UNO Project from OpenOffice in the long run when it comes to deviding the project into smaller Packages. This is a really strong OpenSource move. It creates opportunities for cooperation with other Projects. This is a good long term goal. I only suggest to move along the bottom Layer because i hope for reduced refactoring work. Also I hope that the risk in steering up something bad is lower. So we can have a good success while migrating. On 10/6/18 7:18 AM, Damjan Jovanovic wrote: > 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’s just Svante and it will 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 some >>>> 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 works >>>> and I ‘m >>>>> 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 —all —target=“winXP”. >>>>> >>>>> Since I am unfamiliar with UNO, I can’t 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’t 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’s 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’s 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 system >>>> can have tremendous >>>>> potential for the project, modern build systems integrate perfect with >>>> Visual Studio, >>>>> Xcode, working on an IDE it’s always nice 🙂. >>>>> >>>>> 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 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... >>>>>> >>>>>>> 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 build, >>>> 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/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. >>>>>>>> >>>>>>>> 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 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). >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>>> 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. 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. >>>>>>>>> >>>>>>>>> @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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org For additional commands, e-mail: dev-help@openoffice.apache.org