strepsirrhini/office-gobmx
9
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
office-gobmx/solenv
History
Stephan Bergmann b84ef4d67e Adapt comphelper::ThreadPool to Emscripten's threading needs 
...by keeping the worker threads around by default instead of joining and later
re-spawning them; see 5b1df7709d "Document the
Emscripten threads issue".  But lets be cautious and change the bJoin default
only for Emscripten.

Also, cap the thread pool size to MAX_CONCURRENCY=4 and increase to
-sPTHREAD_POOL_SIZE=6.  In an experimental setup where the Emscripten build
starts up with the start center rather than a Writer document, that is just
enough to cover the thread-spawning needs when executing the start center
window's paint task:  Four threads for the comphelper::ThreadPool (used from
within drawinglayer::convertToBitmapEx -> ... ->
BitmapBasicMorphologyFilter::filter), and one each for
configmgr::Components::WriteThread (see e8358d0a0f
"Keep around a single configmgr::Components::WriteThread instance") and
salhelper::TimerManager.

Change-Id: I5b1d0e9dc09f05fb3b679c8dc1c38ee45c61c0f8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/171004
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
2024-07-25 13:27:53 +02:00
..
bin tdf#82716 Add initial implementation of the Histogram Chart 2024-07-21 08:02:43 +02:00
buck
clang-cl
clang-format Unify/Port to use VCLUnoHelper for AWT <-> VCL conversions 2024-07-11 06:44:48 +02:00
doc/gbuild
gbuild Adapt comphelper::ThreadPool to Emscripten's threading needs 2024-07-25 13:27:53 +02:00
gbuildtojson
gcc-wrappers
gdb solenv: gdb: adapt ItemSetPrinter to unordered_map 2024-07-18 16:38:41 +02:00
inc use gb_StaticLibrary_WORKDIR and gb_Library_DLLDIR more consistently 2024-06-19 20:00:39 +02:00
lldb/libreoffice
lockfile
maven
qa/python
sanitizers tdf#161811 Changes in TC manager dialog should be in order of 2024-07-14 05:31:46 +02:00
vs VS natvis: improve css::uno::Any handling 2024-07-04 14:22:21 +02:00
wsl
CompilerTest_compilerplugins_clang-c++03.mk
CompilerTest_compilerplugins_clang.mk
CustomTarget_gbuildtesttools.mk
Executable_concat-deps.mk
Executable_g++-wrapper.mk
Executable_gbuildtojson.mk
Executable_gcc-wrapper.mk
Executable_lockfile.mk
flatpak-manifest.in Adapt flatpak build to upstream changes 2024-07-09 11:08:43 +02:00
Makefile
Module_solenv.mk
PythonTest_solenv_python.mk
README.md
StaticLibrary_wrapper.mk

README.md

Tools and Makefile Fragments Necessary for Compilation

This module contains many tools and makefile configuration pieces, critical for building LibreOffice:

  • bin/

    • contains lots of tools used during the build:

      • concat-deps* these aggregate, and remove duplicates from module dependencies, to accelerate build times.

      • make_installer.pl this script executes the compiled instructions from the scp2/ module to create an installer, and/or to do a local install for the smoketest.

  • gbuild/

    implementation of the LibreOffice build system See gbuild/README for more info.

  • gdb/

    lots of nice python helpers to make debugging -much- easier that (eg.) print UCS2 strings as UTF-8 on the console to help with debugging.

  • inc/

    old / increasingly obsolete dmake setup and includes, we are trying to entirely rid ourselves of this

  • src/

    useful standard / re-usable component map files for components which shouldn't export anything more than a few registration symbols.

  • flatpak-manifest.in

    This file is copied manually to https://github.com/flathub/org.libreoffice.LibreOffice/blob/master/org.libreoffice.LibreOffice.json The flatpak/build.sh in the LO dev-tools repository is obsolete.