You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@openoffice.apache.org by Peter Kovacs <Pe...@Apache.org> on 2018/09/23 08:46:29 UTC

Windows Build Environment futures (was: Open Office Contribution)

Welcome George!

This sounds like you made up your mind for a long term volunteer 
project, which is awesome.  A big welcome from me. I hope you stay with 
us. Your mail sounds like you do not need much help. The recruitment has 
the Idea to help people to integrate better, by giving them a dedicated 
space to communicate.

Now lets root the discussion in to Dev Mailinglist. Please subscribe 
there. Damjan is our awesome contributer for Windows. If you 2 align 
that would be awesome. Please use the List, so all can participate.

We currently use MSVC 2008 for all releases, Damjan started to migrate 
to MSVC2015. A bigger jump to 2017 is fine for me, but keep in mind that 
we are standard wise behind 10 years the current standard. Especially on 
Linux we support Distributions, that do not have support for c++11. Also 
current conses is to keep Windows XP Compatibility.

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. :(

Hope those answer you some of your questions, and loop you in roughly 
where our status is.

You can try Visual Studio version you like. I do not think MSVS supports 
our code. We have some special features build in historically, that are 
used only in the project. And we strongly use multilanguage 
architecture. So bringing the support to Visual Studio will be also not 
easy.

At Least on Eclipse it is very difficult to get the IDE partial working. 
I am thinking on extending one IDE, and I am undecided if Eclipse is the 
right choice, or maybe netbeans?... Well whatever not your issue. :)

It would be cool if we could establish Windows Visual Studio Suopport or 
any other IDE.

All the best

Peter

The MSVC we use

# 2008: https://www.microsoft.com/en-us/download/details.aspx?id=5023

# 2015: https://www.microsoft.com/de-de/download/details.aspx?id=48145

On 9/22/18 2:27 PM, George K wrote:
> Hello,
>
> I would like to contribute to Open Office. My main area of expertise is
> computer graphics i.e. ui/ux. I have previous experience with DirectX and
> OpenGL. My main focus this couple of years has been mobile development for
> iOS and Android. Also i know design and prototyping.
>
> I want to help make Open Office better and dusty off my C++ skills. I am
> currently trying to build Open Office on the Windows platform and i 've
> faced a problem as Microsoft Windows SDK for Windows 7 and .NET Framework
> 3.5. SP1 is not available to download. So i 'm stuck at the configure step.
> Also is Visual Studio 9 necessary? Can Visual Studio 2017 be used, as i
> can't find the former?
>
> That said, i would like to start by making the build process easier(at
> least on Windows). After many thoughts i 've come up with the following
> build process:
>
> -Install Visual Studio 2017(That means updating the project to work with
> MSVC 2017 and provide all the other libraries and tools needed for Windows
> through the VS installation. So all things Windows would be installed
> through VS).
> -Create a Windows script that will install all other prerequisites and
> check out the repo(Provide a .bat file that will be run from the command
> line which will install Java, Cygwin and it's modules, or install python
> and through python scripts set up all the above. Then checkout the repo
> from svn and be ready for build).
> -Build Open Office as usual.
>
> I know that all this may sound a lot because the whole project must be
> updated to modern tools, but i am willing to try. But first things first, i
> would be grateful if someone cleared my questions above, for the build
> process, and after that get familiar with the code and discuss what would
> work and what not, for making the build process better. And if the later
> were to happen i believe that new users could be onboarded easier on the
> project and start working on features.
>
> Thanks in advance,
> George
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Other build ideas (was: Re: Windows Build Environment futures

Posted by Damjan Jovanovic <da...@apache.org>.

On Fri, Oct 5, 2018 at 8:45 PM George Karalis <th...@gmail.com> wrote:

>
> Hello everyone,
>
>
Hi, welcome :)


> 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”.
>
>
Don't do that. Once the port to gbuild is complete, the "build" command
will disappear. Also the MSVC information is already stored in environment
variables from set_soenv(.in) -> winenv.set.sh like COM, COMID, CCVER,
CCNUMVER, etc.


> 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.
>
>
CMake was already investigated by the original OOo team and found to be
lacking. Unlike CMake's module-at-a-time approach, gbuild and SCons take
the better approach of building a global project-wide list of dependencies
for each and every file, which is deterministic and always correct (unlike
the underspecified/overspecified module dependencies which give
inconsistent build results), and then optimally parallelizing the build at
a file level, instead of the artificial walls between modules limiting
build speed.


> 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 🙂.
>
>
Agreed :).


> Kind regards,
> George
>
>
Regards
Damjan

Re: Other build ideas

Posted by Peter Kovacs <Pe...@Apache.org>.

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 <da...@comcast.net> wrote:
>
>>
>> Sent from my iPhone
>>
>>> On Oct 5, 2018, at 6:37 PM, Damjan Jovanovic <da...@apache.org> wrote:
>>>
>>> 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
>> 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 <Pe...@apache.org> 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 <da...@apache.org> 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 <Pe...@apache.org>
>> 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 <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. :(
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>
>>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Other build ideas

Posted by Damjan Jovanovic <da...@apache.org>.

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 <da...@comcast.net> wrote:

>
>
> Sent from my iPhone
>
> > On Oct 5, 2018, at 6:37 PM, Damjan Jovanovic <da...@apache.org> wrote:
> >
> > 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
>
> 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 <Pe...@apache.org> 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 <da...@apache.org> 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 <Pe...@apache.org>
> 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 <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. :(
> >>>>>>>
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>>>
> >>>>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Re: Other build ideas

Posted by Dave Fisher <da...@comcast.net>.


Sent from my iPhone

> On Oct 5, 2018, at 6:37 PM, Damjan Jovanovic <da...@apache.org> wrote:
> 
> 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

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 <Pe...@apache.org> 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 <da...@apache.org> 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 <Pe...@apache.org> 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 <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. :(
>>>>>>> 
>>>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>>> 
>>>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Other build ideas

Posted by Damjan Jovanovic <da...@apache.org>.

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 <Pe...@apache.org> 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 <da...@apache.org> 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 <Pe...@apache.org> 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 <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. :(
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >>> For additional commands, e-mail: dev-help@openoffice.apache.org
> >>>
> >>>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Re: Other build ideas

Posted by Peter Kovacs <Pe...@Apache.org>.

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 <da...@apache.org> 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 <Pe...@apache.org> 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 <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. :(
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Re: Other build ideas (was: Re: Windows Build Environment futures

Posted by George Karalis <th...@gmail.com>.

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 <da...@apache.org> 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 <Pe...@apache.org> 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 <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. :(
>>>> 
>>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>> 
>>

Re: Other build ideas (was: Re: Windows Build Environment futures

Posted by Damjan Jovanovic <da...@apache.org>.

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 <Pe...@apache.org> 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 <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. :(
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>

Re: Other build ideas (was: Re: Windows Build Environment futures

Posted by Peter Kovacs <Pe...@Apache.org>.

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 <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. :(
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org

Other build ideas (was: Re: Windows Build Environment futures (was: Open Office Contribution))

Posted by Damjan Jovanovic <da...@apache.org>.

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. :(
>
>

The Path to OpenOffice ;)

Posted by Peter Kovacs <Pe...@Apache.org>.

Hi Aryan,

We are still trying to get 4.2.0 into release shape. Currently we have 
to make a 4.1.6 Version. We do not have plans for OpenOffice 5 yet. What 
would you like to see in OpenOffice 5?

But if you want to help you can start by learning how to build 
OpenOffice. We have a guide here what to do.

https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step

OpenOffice is a very complex program and takes some time to learn how to 
do basic things. If you have any Questions. Please ask.

I appreciate if you write what your efforts and successes are so I can 
accompany you. Please write to the recruitment mailing list. So others 
can also review your progress, and help if needed.

All the best

Peter

On 9/23/18 11:31 AM, ASP An Aryan Sinha Presentation wrote:
> Hello there. My name is Aryan Sinha. I'm knowing the Basics of C++, Java,
> Python etc. So I would like to Contribute to Open Office 5
>

Re: Windows Build Environment futures (was: Open Office Contribution)

Posted by ASP An Aryan Sinha Presentation <si...@gmail.com>.

Hello there. My name is Aryan Sinha. I'm knowing the Basics of C++, Java,
Python etc. So I would like to Contribute to Open Office 5

On 23 Sep 2018 2:16 p.m., "Peter Kovacs" <Pe...@apache.org> wrote:

Welcome George!

This sounds like you made up your mind for a long term volunteer
project, which is awesome.  A big welcome from me. I hope you stay with
us. Your mail sounds like you do not need much help. The recruitment has
the Idea to help people to integrate better, by giving them a dedicated
space to communicate.

Now lets root the discussion in to Dev Mailinglist. Please subscribe
there. Damjan is our awesome contributer for Windows. If you 2 align
that would be awesome. Please use the List, so all can participate.

We currently use MSVC 2008 for all releases, Damjan started to migrate
to MSVC2015. A bigger jump to 2017 is fine for me, but keep in mind that
we are standard wise behind 10 years the current standard. Especially on
Linux we support Distributions, that do not have support for c++11. Also
current conses is to keep Windows XP Compatibility.

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. :(

Hope those answer you some of your questions, and loop you in roughly
where our status is.

You can try Visual Studio version you like. I do not think MSVS supports
our code. We have some special features build in historically, that are
used only in the project. And we strongly use multilanguage
architecture. So bringing the support to Visual Studio will be also not
easy.

At Least on Eclipse it is very difficult to get the IDE partial working.
I am thinking on extending one IDE, and I am undecided if Eclipse is the
right choice, or maybe netbeans?... Well whatever not your issue. :)

It would be cool if we could establish Windows Visual Studio Suopport or
any other IDE.

All the best

Peter

The MSVC we use

# 2008: https://www.microsoft.com/en-us/download/details.aspx?id=5023

# 2015: https://www.microsoft.com/de-de/download/details.aspx?id=48145

On 9/22/18 2:27 PM, George K wrote:
> Hello,
>
> I would like to contribute to Open Office. My main area of expertise is
> computer graphics i.e. ui/ux. I have previous experience with DirectX and
> OpenGL. My main focus this couple of years has been mobile development for
> iOS and Android. Also i know design and prototyping.
>
> I want to help make Open Office better and dusty off my C++ skills. I am
> currently trying to build Open Office on the Windows platform and i 've
> faced a problem as Microsoft Windows SDK for Windows 7 and .NET Framework
> 3.5. SP1 is not available to download. So i 'm stuck at the configure
step.
> Also is Visual Studio 9 necessary? Can Visual Studio 2017 be used, as i
> can't find the former?
>
> That said, i would like to start by making the build process easier(at
> least on Windows). After many thoughts i 've come up with the following
> build process:
>
> -Install Visual Studio 2017(That means updating the project to work with
> MSVC 2017 and provide all the other libraries and tools needed for Windows
> through the VS installation. So all things Windows would be installed
> through VS).
> -Create a Windows script that will install all other prerequisites and
> check out the repo(Provide a .bat file that will be run from the command
> line which will install Java, Cygwin and it's modules, or install python
> and through python scripts set up all the above. Then checkout the repo
> from svn and be ready for build).
> -Build Open Office as usual.
>
> I know that all this may sound a lot because the whole project must be
> updated to modern tools, but i am willing to try. But first things first,
i
> would be grateful if someone cleared my questions above, for the build
> process, and after that get familiar with the code and discuss what would
> work and what not, for making the build process better. And if the later
> were to happen i believe that new users could be onboarded easier on the
> project and start working on features.
>
> Thanks in advance,
> George
>