openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damjan Jovanovic <dam...@apache.org>
Subject Re: Other build ideas
Date Sat, 06 Oct 2018 05:18:19 GMT
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 <dave2wave@comcast.net> wrote:

>
>
> Sent from my iPhone
>
> > On Oct 5, 2018, at 6:37 PM, Damjan Jovanovic <damjan@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 <Petko@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 <damjan@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 <Petko@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 <Petko@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
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message