From dev-return-63867-archive-asf-public=cust-asf.ponee.io@openoffice.apache.org Fri Oct 5 19:34:59 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 981CE180649 for ; Fri, 5 Oct 2018 19:34:58 +0200 (CEST) Received: (qmail 25912 invoked by uid 500); 5 Oct 2018 17:34:57 -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 25900 invoked by uid 99); 5 Oct 2018 17:34:57 -0000 Received: from mail-relay.apache.org (HELO mailrelay1-lw-us.apache.org) (207.244.88.152) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 05 Oct 2018 17:34:57 +0000 Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) by mailrelay1-lw-us.apache.org (ASF Mail Server at mailrelay1-lw-us.apache.org) with ESMTPSA id 9A749E1C for ; Fri, 5 Oct 2018 17:34:56 +0000 (UTC) Received: by mail-oi1-f172.google.com with SMTP id a203-v6so11074034oib.0 for ; Fri, 05 Oct 2018 10:34:56 -0700 (PDT) X-Gm-Message-State: ABuFfogLwkPLfNM8B5pLa7Bif7K4HoxFSy4ymy1o5cRtIVKxBV/GNiOy AV4phMf+2A7t23zRfqiR0CA2THrLXtyvURYJJgI= X-Google-Smtp-Source: ACcGV62ei/FUW40rRb0hkkJKY92p2E4O/cJgQBMiX41ztOTpnfk32LL2A8fnqQECvh3Feu0r1sOXPd7vv/UlY9ZLeLA= X-Received: by 2002:aca:f156:: with SMTP id p83-v6mr5068916oih.332.1538760896065; Fri, 05 Oct 2018 10:34:56 -0700 (PDT) MIME-Version: 1.0 References: <3451572b-7a30-c26c-6365-66067c5c6d6d@Apache.org> In-Reply-To: From: Damjan Jovanovic Date: Fri, 5 Oct 2018 19:32:52 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Other build ideas (was: Re: Windows Build Environment futures To: Apache OO Content-Type: multipart/alternative; boundary="0000000000009ab7c905777eb031" --0000000000009ab7c905777eb031 Content-Type: text/plain; charset="UTF-8" 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 > > --0000000000009ab7c905777eb031--