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 <pe...@apache.org> 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. :( > >