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 <p...@apache.org> 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: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > >
