As subsequent_export-test.cxx code style is following the recommended code style (except too long lines and minor formattings), the code is used only for testing and it is rarely modified (mainly adding new test cases), I decided to enable automatic code formatting. It is one step closer to migrate to common code style. Change-Id: Iaa6c243fab45c37cb01672633717577651916c3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120706 Tested-by: Jenkins Reviewed-by: Bartosz Kosiorek <gang65@poczta.onet.pl>
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.plthis script executes the compiled instructions from thescp2/module to create an installer, and/or to do a local install for the smoketest.
-
-
-
gbuild/implementation of the LibreOffice build system See
gbuild/READMEfor 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.inThis file is used by
flatpak/build.shfrom the LOdev-toolsrepository to generate the flatpak package.download.lstis aMakefilesnippet, so there seems to be no easy way to usedownload.lstfor the manifest generation (build.shusessed), and its information must be kept in sync manually.