History

Stephan Bergmann a45f057d9d Remove COMPILER_PLUGINS_CXX from distro-configs/Jenkins/linux_clang_dbgutil_64 It had originally been added with `e754d0931c` "Remove CXXFLAGS_CXX11 from Clang plugin compilation", so "if COMPILER_PLUGINS_CXX is not set, simply default it to g++ instead of trying to construct an acceptable CLANGCXX value from CXX (which would be Clang). (The problem with using Clang without CXXFLAGS_CXX11 is that Clang, unlike GCC, typically defaults to C++03, but building compilerplugins requires C++11 at least. That would cause e.g. the Gerrit/Jenkins linux_clang_dbgutil_64 builds to fail---but which also needs COMPILER_PLUGINS_CXX to be explicitly set to 'g++ -std=c++11' as GCC on those machines is still 4.8.5 defaulting to C++03." But that should no longer be an issue with contemporary Clang, which defaults to >= C++11 for quite a while now. On the other hand, when trying to update the Clang used by <https://ci.libreoffice.org/job/gerrit_linux_clang_dbgutil/> from 5.0.2 to 12.0.1, and adding > export COMPILER_PLUGINS_CXX="ccache $LODE_HOME"/opt_private/gcc-7.3.0/bin/g++ to <https://git.libreoffice.org/lode/+/refs/heads/master/bin/linux_clang_dbgutil_64.env> (where this setting arguably belongs, rather than in distro-configs/Jenkins/linux_clang_dbgutil_64, anyway), which is needed because that version of Clang (and thus loplugin built against it) cannot be built with the baseline CentOS 7 GCC 4.8.5, that setting of COMPILER_PLUGINS_CXX got overriden by the one in distro-configs/Jenkins/linux_clang_dbgutil_64, and configure failed due to > configure:21069: checking clang/Basic/SourceLocation.h usability > configure:21069: ccache g++ -std=c++11 -c -I/home/tdf/sberg/lode/opt_private/clang-llvmorg-12.0.1/include -std=c++14 -fno-exceptions -fno-rtti -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/home/\ > tdf/sberg/lode/packages/llvm-llvmorg-12.0.1.src/clang/include -I/home/tdf/sberg/lode/opt_private/clang-llvmorg-12.0.1/include -std=c++14 -fno-exceptions -fno-rtti -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_L\ > IMIT_MACROS -I/home/tdf/sberg/lode/packages/llvm-llvmorg-12.0.1.src/clang/include conftest.cpp >&5 > g++: error: unrecognized command line option '-std=c++14' > g++: error: unrecognized command line option '-std=c++14' > configure:21069: $? = 1 Change-Id: Ic33b116090f648ef645febb4fbb28ceb6a2a7cae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129692 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>		2022-02-08 23:55:50 +01:00
..
Jenkins	Remove COMPILER_PLUGINS_CXX from distro-configs/Jenkins/linux_clang_dbgutil_64	2022-02-08 23:55:50 +01:00
CPAndroid.conf
CPAndroidAarch64.conf
CPAndroidBranding.conf
CPAndroidX86.conf
CPAndroidX86_64.conf
LibreOfficeAndroid.conf
LibreOfficeAndroidAarch64.conf
LibreOfficeAndroidX86.conf
LibreOfficeAndroidX86_64.conf
LibreOfficeCoverity.conf
LibreOfficeFlatpak.conf
LibreOfficeHaiku.conf
LibreOfficeiOS.conf
LibreOfficeiOS_Sim.conf
LibreOfficeLinux.conf
LibreOfficeMacOSX.conf
LibreOfficeOnline.conf
LibreOfficeOpenBSD.conf
LibreOfficeOssFuzz.conf	ofz#43613 oss-fuzz build failure	2022-01-13 21:02:41 +01:00
LibreOfficeVanillaMacAppStore.conf
LibreOfficeWASM32.conf	WASM add strip flags to configure.ac	2022-01-19 12:00:48 +01:00
LibreOfficeWin32.conf
LibreOfficeWin64.conf
LibreOfficeWinArm64.conf
README.md

README.md

Pre-canned Distribution Configurations

These files are supposed to correspond to the options used when creating the Document Foundation (or other "canonical") builds of LibreOffice for various platforms. They are not supposed to represent the "most useful" options for developers in general. On the contrary, the intent is that just running ./autogen.sh without any options at all should produce a buildable configuration for developers with interest in working on the most commonly used parts of the code.

See https://wiki.documentfoundation.org/Development/ReleaseBuilds for how TDF builds make use of these switches. (Especially, since --with-package-format now triggers whether or not installation sets are built, all the relevant *.conf files specify it, except for LibreOfficeLinux.conf, where the TDF build instructions pass an explicit --with-package-format="rpm deb" in addition to --with-distro=LibreOfficeLinux.)

(Possibly the above is a misunderstanding, or maybe there never even has been any clear consensus what situations these files actually are intended for.)

The files contain sets of configuration parameters, and can be passed on the autogen.sh command line thus:

./autogen.sh --with-distro=LibreOfficeFoo

Contrary to the above, in the Android case the amount of parameters you just must use is so large, that for convenience it is always easiest to use the corresponding distro-configs file. This is a bug and needs to be fixed; also configuring for Android should ideally use sane (or the only possible) defaults and work fine without any parameters at all.