lo/core - LibreOffice 核心代码仓库

LibreOffice 核心代码仓库

文档基金会

path: root/setup_native/Library_sdqsmsi.mk

Age	Commit message (Expand)	Author
2013-04-15	gbuild: add support for building against MSVC debug runtime	Michael Stahl
2013-02-17	CustomActions should be statically linked with MSVCRT	Andras Timar
2013-02-13	fix exported DLL function names for all CustomActions	Andras Timar
2013-02-09	convert setup_native to gbuild and add to tail_build	Peter Foley

LD_TYPE items to match complex build conditions and then patch the component file with it, filter the component files based on the unique implementation name and an <optional/> tag. Currently these optional implementations are grouped in external files with an identifier. Originally the optional implementations were automatically iden- tified by adding them to any external file, but this behavior is too easy to get wrong. Even better: if need arrises, one can now easily implement a feature to add implementation names directly using gbuild calls, instead of grouped files. The basic mechanism is to collect all optional implementations, remove the needed ones from that list and then filter-out all implementations not needed (AKA the rest of the list). It's no problem to have the same optional implementations selected in multiple files. This is especially used by the vcl.common component in a later patch. For gbuild this adds gb_Library_add_componentimpl. The component parameter for the call is explicitly omitted, so you must call gb_Library_set_componentfile before selecting any optional implementations. The strict naming is also enforced by appending the identifier to the component file name. This replaces commit 65c0887bca2909b2046eb5aa4aaace0cc320c3f2 ("Allow for conditional parts of component files"). Change-Id: I0261cadce8bdfebb6b3ec96669ec378a5c1d9699 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126891 Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins 2021-12-14Allow for conditional parts of component filesStephan Bergmann 1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built components" had moved parts of svx/util/svx.component and sw/util/sw.component into additional, conditionally included component files (and which this commit moves back into the original component files). But that lead to multiple <component> elements for a single library in service rdb files, which was unfortunate for several reasons: For one, while the code in cppuhelper/source/servicemanager.cxx happened to support that, it was not guaranteed to support it, so this relied on an implementation detail of that code. And for another, for that to work, all the component files for a library had to provide identical environment, loader, and prefix (if any) attributes, but which was not verified and thus was brittle. Instead, introduce a CONDITION attribute for the <implementation> elements in the source component files, which decides whether or not such <implementation> elements are passed through (after dropping the CONDITION attribute) into the processed component files (in workdir/ComponentTarget/). (The attribute is spelled all-uppercase to make it more obvious that it is special syntax that is not simply passed through to the output component file.) For now, such a CONDITION attribute must have a value that matches BUILD_TYPE:x for some feature x in $(BUILD_TYPE), but the syntax can be extended if the need arises. (gb_Library_set_componentfiles is thus no longer needed and has been removed again.) Change-Id: I360cf4cc0f3a2a738113d430891500715a8fe3a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126560 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2021-12-06gbuild: create services.rdb from built componentsJan-Marek Glogowski ... and introduce the --enable-services-rdb-from-build option. Currently the build handles global build options redundant in a few places: * in Repository*mk + modules - the "real" build dependencies * the full services.rdb generation * the static UNO constructor map generation Also the component files don't reflect the really built components and so the RDB services generation must handle the whole options to select the correct components. So this optionally replaces the latter two by generating the list of components and it's constructors from the build itself. As a consequence, component files must now be split, so they reflect the real components in the libraries, otherwise the static constructor list will have missing symbols. IMHO this is more natural, as it happens in the same place already handling these build options for the sourcecode. This also adds a convenience helper to add multiple component files: gb_Library_set_componentfiles This is WIP and currently just works for the stripped WASM build, which introduces many more split component files in later patches. It also explicitly filters the gb_Rdb__URECOMPONENTS and the CppunitTest related components from the services.rdb. Maybe there is a good way to do this properly. Change-Id: I1b38a6f2c1e5221f18d7e5e756c30263b555d962 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126185 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>