Future development discussion

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Future development discussion

Pedro Giffuni
Hi again;

I just wanted to stop by and share some ideas of things that need to be
done in AOO after 4.2.

Easier things:

OpenSSL has to be updated, yet again, and while the future versions will
be under an Apache License, making things nicer for us, the API has been
changing so we may need some adaptations to work with future versions.

Python 3: our compiler toolchain for MS-Windows is ancient enough that
it is difficult to update internally to a recent Python 3 version. We
have been supporting python 3 through external packages: configuring the
AOO to build with Python 3 worked but, as found be FreeBSD's builds, it
recently broke. I don't have more details this needs more investigation
(and fixing).

And now the tougher thing:

I absolutely appreciate the huge effort Damjan has been doing with the
build system: getting rid of Dmake is a viable objective that needs to
be pushed forward.

I have been playing a bit with clang-cl, which appears to be the only
opensource compiler that can work with native windows binaries: it
integrates into MS-Visual Studio but it requires CMake. I also happen to
have met a developer of the Bazel build system which seems interesting
and would suit our purposes in many ways but I have no interest in
having long discussions about build systems. The central thing that we
*have* to do is update the windows toolchain: MSVisual Studio 2015 seems
to be the minimum that is suficiently popular and basically required
nowadays.

After that, there is a huge technical debt. Of course, pivot charts,
newer ODF and better docx support would be very nice to have but without
the proper tooling, especially on Windows, we have one hand tied.

All just my 0.02$.

Pedro.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future development discussion

Damjan Jovanovic
Win64 is also making good progress behind the scenes. The uncommitted Win64
UNO bridge I've been coding (a lot of it in AMD64 assembly) should now be
able to call arbitrary C++ methods from UNO and UNO methods from C++ (not
tested yet), but the poorly documented internals of MSVC C++ exception
handling are still TODO.

I also played a bit with mingw-w64 (an independent and alternative
mingw-like project capable of producing both Win32 and Win64 binaries) as
an alternative C++ compiler on Windows, but its MSYS2 environment can't
easily replace Cygwin due to using /c instead of /cygdrive/c, so a
tremendous amount of patching configure.ac, set_soenv.in, and many Perl
scripts that assume /cygdrive would be required. Using Cygwin instead of
MSYS2 might be more successful, but since GCC has different exception
handling to MSVC, Windows builds would need to be debugged with gdb instead
of Visual Studio, and AOO extensions would need to be built with mingw and
would be incompatible with the MSVC extensions. Also either we would need
the ship the GCC C and C++ runtimes, or link them statically and have
bloated binaries. It's worth noting LO gave up on mingw.

Where mingw could really help though, is building Windows binaries quickly
for testing purposes. Since Windows builds very slowly, and *nix builds
quickly, we could build a Windows version on *nix at *nix speeds by
compiling it in this setup:
mingw
Cygwin
Wine
*nix
;-)

We could also try a more ambitious setup of Windows Platform SDK in place
of mingw there, but how well it works on Wine is an open question.

Damjan

On Thu, Jan 10, 2019 at 6:24 PM Pedro Giffuni <[hidden email]> wrote:

> Hi again;
>
> I just wanted to stop by and share some ideas of things that need to be
> done in AOO after 4.2.
>
> Easier things:
>
> OpenSSL has to be updated, yet again, and while the future versions will
> be under an Apache License, making things nicer for us, the API has been
> changing so we may need some adaptations to work with future versions.
>
> Python 3: our compiler toolchain for MS-Windows is ancient enough that
> it is difficult to update internally to a recent Python 3 version. We
> have been supporting python 3 through external packages: configuring the
> AOO to build with Python 3 worked but, as found be FreeBSD's builds, it
> recently broke. I don't have more details this needs more investigation
> (and fixing).
>
> And now the tougher thing:
>
> I absolutely appreciate the huge effort Damjan has been doing with the
> build system: getting rid of Dmake is a viable objective that needs to
> be pushed forward.
>
> I have been playing a bit with clang-cl, which appears to be the only
> opensource compiler that can work with native windows binaries: it
> integrates into MS-Visual Studio but it requires CMake. I also happen to
> have met a developer of the Bazel build system which seems interesting
> and would suit our purposes in many ways but I have no interest in
> having long discussions about build systems. The central thing that we
> *have* to do is update the windows toolchain: MSVisual Studio 2015 seems
> to be the minimum that is suficiently popular and basically required
> nowadays.
>
> After that, there is a huge technical debt. Of course, pivot charts,
> newer ODF and better docx support would be very nice to have but without
> the proper tooling, especially on Windows, we have one hand tied.
>
> All just my 0.02$.
>
> Pedro.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Future development discussion

Jim Jagielski
In reply to this post by Pedro Giffuni
+1 on doing what we can to move to gbuild as appropriate, but we also need
to find out what our long term plan is, esp as related to non-*Nix platforms.

I hope to get macOS more up-to-date and part of that is fixing the longstanding
confusion regarding UDK library versioning. Currently, AOO forces macOS to
follow the *Nix standard (libfoo.so.3, etc) which is NOT how macOS does it
(libfoo.3.dylib, NOT libfoo.dylib.3). I am working on this now, which should
be a step in the right directly and the plan is that this be part of 4.2.x
(might as well bite the bullet now since macOS doesn't build yet and
fails during the packaging phase now with the movement of some
libs to "real" UDK versioning via gbuild (and not dmake).
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future development discussion

Peter Kovacs-3
Okay, have all special quick points to my OpenOffice overview[1]. (I
skipped the ODF, and Pivot part, since there are plenty Bugzilla Issues
which I will find at some point in the future ;P )

I think we have a lot of technical Debt, and Issues that needs to be
fixed. Not only in the building environment.

As we see on the HTML filter, and the feedback it is also not easy to
enhance here.

And to the least, we are a multilanguage Project, which I found none IDE
supporting to my satisfaction. The best is Eclipse and that one handles
it not very well.


I hope with the Overview we can create a Roadmap in the future and
support people that are interested in topics with pointers what to look
out for.


All the Best

Peter


[1] https://issues.apache.org/jira/secure/RapidBoard.jspa?rapidView=301




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Future development discussion

Pedro Giffuni-2
In reply to this post by Pedro Giffuni
> Win64 is also making good progress behind the scenes. The uncommitted Win64
> UNO bridge I've been coding (a lot of it in AMD64 assembly) should now be
> able to call arbitrary C++ methods from UNO and UNO methods from C++ (not
> tested yet), but the poorly documented internals of MSVC C++ exception
> handling are still TODO.
>
> I also played a bit with mingw-w64 (an independent and alternative
> mingw-like project capable of producing both Win32 and Win64 binaries) as
> an alternative C++ compiler on Windows, but its MSYS2 environment can't
> easily replace Cygwin due to using /c instead of /cygdrive/c, so a
> tremendous amount of patching configure.ac, set_soenv.in, and many Perl
> scripts that assume /cygdrive would be required. Using Cygwin instead of
> MSYS2 might be more successful, but since GCC has different exception
> handling to MSVC, Windows builds would need to be debugged with gdb instead
> of Visual Studio, and AOO extensions would need to be built with mingw and
> would be incompatible with the MSVC extensions. Also either we would need
> the ship the GCC C and C++ runtimes, or link them statically and have
> bloated binaries. It's worth noting LO gave up on mingw.
>
> Where mingw could really help though, is building Windows binaries quickly
> for testing purposes. Since Windows builds very slowly, and *nix builds
> quickly, we could build a Windows version on *nix at *nix speeds by
> compiling it in this setup:
> mingw
> Cygwin
> Wine
> *nix
> ;-)
>
> We could also try a more ambitious setup of Windows Platform SDK in place
> of mingw there, but how well it works on Wine is an open question.
FWIW, clang-cl from LLVM is really easy to install:

http://www.llvm.org/builds/

The thing is, libc++ hasn't been ported yet to Windows, so it depends on
the Visual Studio libraries for everything.

All in all it is likely a better option than mingw, or cygwin.

Pedro.