openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Kovacs <>
Subject Re: Other build ideas
Date Sat, 06 Oct 2018 09:40:02 GMT
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:
>> 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.
>>>> 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.
>>>> 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
>>>> 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
>>>> 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
>>>> switched  <>
>>>>> to CMake <> was an interesting
>>>> 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 <>
>>>>>> The split wouldn't help us with newer MSVC as such.
>>>>>> What would help us there a lot, is SCons, as SCons supports many
>>>>>> versions already, including MSVC 2017. It would be so wonderful if
>>>> 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
>>>>>> testing would be necessary on all platforms, and we don't have a
>> 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
>>>>>>> (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
>> 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
>>>> reimplemented
>>>>>>>> on SCons. But there are advantages to redoing stuff in SCons:
>>>>>>> example,
>>>>>>>> we could run code in Python instead of calling external tools
>>>> awk,
>>>>>>> tr
>>>>>>>> and sed, and thus gain more portability, reduce dependencies,
>>>> ditch
>>>>>>>> Cygwin.
>>>>>>>> However I consider SCons lower priority than a 64 bit Windows
>>>> 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.
>> of
>>>> my
>>>>>>>> ideas is to split up AOO into 2 layers: an UNO layer at the
>>>> and
>>>>>>> an
>>>>>>>> office layer at the top. This is something that's been in
>> 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/
>> 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
>> 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,
>>>> and
>>>>>>>> packaged independently of AOO (eg.,
and is a
>>>>>>> just a
>>>>>>>> compile-time and run-time dependency for us, that we download,
>>>> 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,
>>>> 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;
>>>> infamous
>>>>>>>> HRESULT with its bitfields).
>>>>>>>> Almost all the UNO modules are using gbuild already (it's
>>>> 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,
>>>> 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 to
>>>>>>> change
>>>>>>>> to not depend on the modules that move. Nothing would initially
>>>> improve;
>>>>>>>> only after other changes could dependencies be reduced. Not
>>>>>>> Cygwin
>>>>>>>> requires both UNO and office to use SCons, a Win64 office
>>>> requires
>>>>>>>> both. The biggest initial benefit might be that since UNO
>>>> change
>>>>>>>> often, rebuilding would be faster, as only office modules
>>>> 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.
>>>> 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
>> support
>>>>>>>>> 64bit has been started. The build currently breaks somewhere.
>>>>>>>>> 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
>>>> 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:
>>>>>>> For additional commands, e-mail:
>>>> ---------------------------------------------------------------------
>>>> 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