openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <>
Subject Re: Other build ideas
Date Sat, 06 Oct 2018 01:53:51 GMT

Sent from my iPhone

> On Oct 5, 2018, at 6:37 PM, Damjan Jovanovic <> wrote:
> The links you are looking for are:

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.


>> 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.
>> 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 <>
>>>>> 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
>> 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,
>>>>>> 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
>>>>>> 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
>> think
>>>>> it
>>>>>> should be a completely separate project, that is hosted, developed,
>> and
>>>>>> packaged independently of AOO (eg., and is
>>>>> 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
>>>>> 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,
>>>>>> 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
>>>>> 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
>>>>>>> 64bit has been started. The build currently breaks somewhere.
>>>>>>> continuation would be awesome.
>>>>>>> And we are moving the build environment from dmake to gmake.
>> 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
>> did
>>>>>>> not drive this topic much. :(
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail:
>>>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message