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
Let's leave the split for now. It's not going to help us directly. On Fri, Oct 5, 2018 at 11:59 PM Peter Kovacs <[email protected]> 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 <https://lwn.net/Articles/188693/> > > to CMake <https://lwn.net/Articles/188693/> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
