Am 05.11.2026 um 20:03 schrieb Jim Jagielski:
On Nov 4, 2026, at 11:51 PM, petko.apache.org via dev
<[email protected]> wrote:
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 is the overall impact of the bazel migration? Is it required for all other
platforms as well? Does it increase the floor for Linux, FreeBSD, macOS, etc.
How solid and reliable is the migration? Does it require major updates of other
dependencies? Is it intended to replace the entire build system?
The currently it is not in the position to challenge our build system.
It is more mature then SCONs port. My understanding is that our current
build system has not many friends. If bazel wins the hearts i leave to
you. It won mine but if we have something different with similar
features then i am fine. I usually do not like to build trunk.
The way i did set up the build made the bazel-migration incompatible
with trunk. And the reason is separation of concerns. The transition is
not 100%, but as much i have setup that porting between both is still
possible.
The seperation of concerns is
https://github.com/apache/openoffice/tree/bazel-migration/build contains
code, scripts, tools that are necessary for building. build contains
build instructions for build environment stuff like ratscan, and so on.
in trunk the stuff that is maintained here is mainly stored in solenv
and instsetoo_native.
https://github.com/apache/openoffice/tree/bazel-migration/ext_libraries
is a repository for build instructions external dependencies. Bazel can
use the build tool of the depenency, or it can override with its own
instructions.
in trunk there is no clear seperation. the modules reside in main, and
you can only identfy if you look into the module.
Bazel has a speciallity, since there is a public repo which allows us to
bind those modules, and relieves us from maintaining the package. We
only need to set the dependency.
https://github.com/apache/openoffice/tree/bazel-migration/main contains
only the source code.
in trunk it is a mix of the concerns.
Bazel builds outsede, and creates a new output per build axis.
Bazel tracks changes not by modified time, but by change. Bazel is able
to track change impact through the complete build. This results in more
stable builds, because dependencies are better tracked. The improved
dependency tracking is exported in a LSP, which at least claude uses to
better understand the code through generators. (less tokens i think)
A bazel fresh build builds with 16 parallel threads without incidant. (i
had issues with debug build, but mainly because the VS2008 linker is not
able to work in parallel. Have not tried debug build with the new stack.)
Bazel massivly caches results. A build action that is not changed is not
executed again. development build round trip can shrink to a view minutes.
If in error the error is always on the bottom, including the issue.
Bazel replaces the perl build script, dmake, gnumake and ant. On windows
no cygwin or msys is needed. you need java, python ond bazel plus build
tool. If bazel needs makes it knows how to build it and handles it for you.
Bazel is distribution aware. At least Debian i know it is covered. I
expect that on linux we cand integrate distribution specific builds as
we can create a community build that is not layed out for a specific
distribution.
Bazel can handle multiple axis. we can add axis and pull different
dependencies or set options ore what ever else you imagine. Bazel is an
Apache Licensed build environment.
I hope this answers your questions.
--
Jim
"This is an outrage!"
Tony Harrison
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
