Am 05.11.2026 um 05:16 schrieb Pedro F. Giffuni via dev:
Hi;
Ah well ... I started a small update to our jpeg
support:https://github.com/pgiffuni/openoffice/tree/libjpeg-turbo
Unfortunately with those patches I now get a complaint that sinc_pi, which we
use from boost requires C++14. Why it doesn't complain now? Who knows, we have
a mess mixing very old language features and Boost doesn't help.
So I am working on a patch that fixes all the deprecated C++ warning issues
reported by clang/libc++; the patch is currently 2.7M and growing. I will
create a new branch as soon as I get something that compiles. After that I will
try to reduce a bit the Boost footprint as well. This is not meant for 5.0.
Concerning future roadmap: we need color
management.https://littlecms.com/tags/lcms2/
Oh and I installed CLion (free for Apache devs) with bazel support but I can't
figure out how to build AOO.
The bazel-migration is still ongoing and not complete. rhino and
beanshell are not migrated. it builds only en-US at this point and
installers are not ready yet. Still windows only.
what you need to setup is a .bashrc and a user.bazel file. there should
be a guide. however it has not been updated, and i droped VS2008 support
on the code. I forgot about the VS2008 integration within the build
environment. i will change that.
for simplification i add now my files need to be stored in git-root
folder. above main:
.bashrc:
# .bazelrc
try-import %workspace%/user.bazelrc
# Use bzlmod
common --enable_bzlmod
common --check_direct_dependencies=off
# Materialize the runfiles symlink tree on Windows (default-off there).
Required
# for tests that resolve files at runtime via %TEST_SRCDIR% (e.g. JNI
tests that
# put native libs on java.library.path). Staged gtest tests are unaffected.
build --enable_runfiles
# Compile all Java to the Java 8 baseline (class file version 52). AOO's
Java
# baseline is 8; the runtime JRE (and the 32-bit JVM the JNI bridge
tests host)
# is Java 8, so jars must load there. Without this, rules_java's bundled
JDK emits
# class 55 (Java 11), which a Java 8 JRE rejects with
UnsupportedClassVersionError.
build --java_language_version=8
common --registry="file:///%workspace%/ext_libraries"
common --registry=https://bcr.bazel.build
# ----------------------------- Target platform
-----------------------------
# win7-x64 (VS2019 toolset + Windows 10 SDK, Windows 7 SP1 and later) is the
# only target and the default: a plain `bazel build` is that build. The
config
# pins --platforms + --platform_suffix (its own bazel-out tree) +
# --symlink_prefix, so a further config can be added beside it without
either
# clobbering the other. Thin alias only: the SEMANTICS (target Windows
floor,
# and any deps/defines that vary by it) live in the
# //build/constraints:win_version constraint carried by the platform,
NOT here.
#
# The winXP-x86 (default until then) and winXP-x64 configs, both VC9 /
VS2008,
# were retired 2026-11-01. Their bazel-winXP-* output trees are no longer
# written; delete them by hand to reclaim the disk.
build --config=win7-x64
build:win7-x64 --platforms=//build/platforms:win7-x64
build:win7-x64 --platform_suffix=win7-x64
build:win7-x64 --symlink_prefix=bazel-win7-x64-
# ── --config=timelog — AOO's own startup/exception tracing
───────────────────
# sal/inc/rtl/logfile.hxx gates every RTL_LOGFILE_CONTEXT/_TRACE macro
behind
# TIMELOG; without it they all compile to ((void)0), and desktop's
Desktop::Main
# is densely instrumented with exactly those. rtl_logfile itself is NOT
gated —
# it reads the RTL_LOGFILE bootstrap variable at runtime — so only the
call sites
# need switching on, and that is a pure compiler define, no source change.
#
# Orthogonal to the platform configs above: combine it with any of them,
e.g.
# bazel build --config=timelog //main/staging:install
# soffice.exe -env:RTL_LOGFILE=C:/temp/oo -env:UserInstallation=...
# writes C:\temp\oo_<pid>.log — logfile.cxx appends "_<pid>.log" unless
the value
# ends in ".nopid", in which case it is used verbatim. Without
--config=timelog
# the same env var still works but yields only the handful of
# RTL_LOGFILE_PRODUCT_* points, which is enough to tell how far startup got.
#
# CRASH-vs-CLEAN-EXIT TEST, free with any of the above: the final line
# "closing log file at <n>" is written by LoggerGuard::~LoggerGuard(), a
STATIC
# DESTRUCTOR. Those run on normal CRT teardown and are skipped by _exit(),
# which is what desktop's FatalError() calls. So a log ending in that line
# exited cleanly; a log that just stops was killed.
#
# NOTE the suffix/prefix below come LAST and therefore win over the platform
# config's, which is deliberate: a traced build gets its own output tree
instead
# of invalidating the normal one.
build:timelog --copt=/DTIMELOG
build:timelog --platform_suffix=timelog
build:timelog --symlink_prefix=bazel-timelog-
user.bazelrc
# Windows MSVC (VS2008 / VC9, 32-bit target) — custom toolchain in
//build/toolchain
build --repo_env=BAZEL_DO_NOT_DETECT_CPP_TOOLCHAIN=1
# VS2008 and Windows SDK install paths — uncomment and edit if not at
the default locations:
build --repo_env="VS_PATH=C:/Program Files (x86)/Microsoft Visual Studio
9.0"
build --repo_env="SDK_PATH=C:/Program Files/Microsoft SDKs/Windows/v7.0"
build --repo_env="MSVC_TMP=C:/Users/legin/AppData/Local/Temp"
build --repo_env="PERL_PATH=C:/msys64/usr/bin/perl.exe"
# Modern toolchain (the win10-x64 target — see
win10-minimal/README.md). Both
# roots are auto-discovered under these; the VERSION pins below are
optional and
# select "newest complete install" when absent.
build --repo_env="VS_MODERN_PATH=C:/Program Files (x86)/Microsoft Visual
Studio/2019/BuildTools"
build --repo_env="WIN10_SDK_PATH=C:/Program Files (x86)/Windows Kits/10"
# Pinned, not newest: two SDKs are installed here (10.0.19041.0 and
10.0.26100.0)
# and 19041 is the one the M0 conformance measurement was taken
against. Staying
# on it keeps any M3 compile failure attributable to the tree rather
than to an
# SDK the sample never saw. Drop the pin to move to the newest.
build --repo_env="WIN10_SDK_VERSION=10.0.19041.0"
#build --repo_env="MSVC_TOOLSET_VERSION=14.29.30133"
build --//build:lang_de=True --//build:lang_fr=True
# Debug symbols: bazel build --config=dbg <target>
# Keeps fastbuild CRT (/MD, no iterator-debug checks) but adds /DEBUG to all
# link steps so the linker emits .pdb files alongside each binary/DLL.
# /Z7 and /Od are already in fastbuild_feature so no recompilation is
needed.
# No --jobs=1 needed: link.exe runs through the mspdbsrv-endpoint wrapper
# (vs_config_repo.bzl), so concurrent /DEBUG links each get a private
# mspdbsrv.exe instead of fighting over one (was LNK1318 0x6BA).
#build:dbg --features=generate_pdb
# Debugging session: build symbols by default so `bazel build
//main/staging:install`
# stages .pdb files into program/ with no extra flags.
# debug_info=True → flat_install copies .pdb alongside DLLs/EXEs
# compilation_mode=dbg → /MDd debug CRT, /Z7 + /Od
# generate_pdb → linker emits the separate .pdb (/Z7 alone
does not)
# Builds stay fully parallel — the link wrapper isolates mspdbsrv per
action.
#build --//build:debug_info=True --compilation_mode=dbg
#build --features=generate_pdb
the following build command gathers all files in one build folder:
bazel build //main/staging/
all tests are executed with
bazel test //main/...
be aware that some test fail that are not run on trunk.
Pedro.
On Wednesday, November 4, 2026 at 10:31:28 PM GMT-5, Petko.apache.org via dev
<[email protected]> wrote:
Hi all,
I would like to put (again) the windows roadmap on the table. I have the
feeling that there is still a disagreement how we move and what to do.
What i would like to propose a 2 step modernization.
The goal is AOO6. I see following features in AOO6
- 4k support and multimonitor or variable dpi support
- windows (native?) theming, allowing at least dark mode, contrast mode.
- accessibility that work with readers. At least support windows reader,
but if we get 3rd party software to work too that would be awesome.
maybe other things i do not know about at the moment.
Why not AOO5. The answer is simple.
- momentum
it would push a release further back. I tried 4k support and variable
DPI, and while it worked it was a rabbit whole. I started to run into
small issues that created small frictions in the code.
I want to prepare for the changes, clean up code that does not support a
modern UI. (that does not mean AOO will look different. It means adding
the features to support the development that is normal today.
- change size.
The chang got really big. I want to split it into smaller chunks and
have it tested and create robust code.
Now where does it end then for AOO5.
I propose
- AOO5 floor is win7
- AOO API does not or minimal change from the win2k / winXP API, because
we know it works.
- Focus on modernizing the code base first.
-- cuting off 4.1.X
-- VLC modernization
-- fix optical bugs for a decent codebase. (examples are, if you have an
arabic or hebrew text the mark tool is really wrong. It marks the right
words but it is an optical glitch. On dxt there are some grafic errors,
which seem to have their root cause in the code which draws on the canvas.)
-- we will bump C++ standards internally pretty quickly once AOO5 has
taken over from 4.1.X
-- probably bumbing java standards too? not sure.
- python is an issue. For python 3.11.15, that we have in trunk i back
ported the compatibility already to win7. the project maintains only
compatibility to 8.1 which does not make sense in my eyes. Since win8 is
irrelevant. So far i think it works.
I think the floor in win7 is a small effort to maintain. It will not
slow development. It is a continuation of our principles.
And if we release AOO6, we still can easy backport fixes to AOO5 if the
communtiy has win7 in use and requests it
Which i think makes a difference in our communication to our users who
value long term support. Plus we do support the spirit of the EU cyber
resilience act without the need to do so.
Imho this would be a strong statement against industrial decay.
I hope this plan is convincing and makes sense. In addition I hope i
could make my point why flooring on win7 is not a step back. and does
not block.
I am looking forward to your comments.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
