ed583bf8d5
This introduces two concepts: a plugin and its loader (library) LO currrently has dependency cycles for some libraries. There is scui, which depends on sc, while sc dlopen's scui. There are the various vclplug_*, i18npool plugins, filters/gie, acc, etc. Usually these plugins link to their loader library, because they use its symbols. But as a result there is no sensible way to express the runtime dependency of loaders on the plugins. In GNU libtool plugins are called modules and they are implemented in an IMHO more sensible way by allowing missing symbols at link time. This way you can have a dependency from the loader library to its plugins, as the plugins don't depend on the loader, but you lose the link time detection of missing symbols. While this is in theory possible in LO too, LO currently has plugins, like acc (accessibility), loaded by tk (toolkit), which depends on svt (svtools), which itself depends on tk, so dropping the tk dependency for acc on its own doesn't help :-( And while the dependency of the plugins on their loader is fine for the shared / DYNLOADING build, for the "static" builds you must (somehow) link the plugins into the executables. I also codeified a few rules into the build system along with it: * just plugins are allowed to depend / link other plugins * plugins aren't allowed to be linked into the merge lib * plugin loaders are "limited" to libraries At the high level, this is implemented via new gbuild calls: * gb_Library_set_plugin_for,lib,loader: declare a library to be a plugin of a loader library and add a dependeny from the plugin library to the loader library * gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding the library dependeny * gb_Helper_register_plugins_for_install: "plugin" replacement for gb_Helper_register_libraries_for_install to implement some additional checks in the build system In the end this patch just adds a bit syntactic sugar and nothing changes for any build. Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> |
||
|---|---|---|
| .. | ||
| inc | ||
| qa | ||
| source | ||
| uiconfig/ui | ||
| AllLangMoTarget_flt.mk | ||
| Configuration_filter.mk | ||
| CppunitTest_filter_dialogs_test.mk | ||
| CppunitTest_filter_msfilter.mk | ||
| CppunitTest_filter_priority.mk | ||
| CppunitTest_filter_svg.mk | ||
| CppunitTest_filter_textfilterdetect.mk | ||
| CppunitTest_filter_xslt.mk | ||
| CustomTarget_svg.mk | ||
| IwyuFilter_filter.yaml | ||
| JunitTest_filter_complex.mk | ||
| Library_filterconfig.mk | ||
| Library_graphicfilter.mk | ||
| Library_icg.mk | ||
| Library_msfilter.mk | ||
| Library_odfflatxml.mk | ||
| Library_pdffilter.mk | ||
| Library_storagefd.mk | ||
| Library_svgfilter.mk | ||
| Library_t602filter.mk | ||
| Library_textfd.mk | ||
| Library_xmlfa.mk | ||
| Library_xmlfd.mk | ||
| Library_xsltdlg.mk | ||
| Library_xsltfilter.mk | ||
| Makefile | ||
| Module_filter.mk | ||
| Package_docbook.mk | ||
| Package_xhtml.mk | ||
| Package_xslt.mk | ||
| README.md | ||
| UIConfig_filter.mk | ||
LibreOffice Filters
Filter registration and some simple filters (also descriptions).
Desperate splitting of code into small shared libraries for historical
reasons presumably (OS/2 and Windows 3.x). The libraries produced from
the code in each subdirectory of filter/source/graphicfilter are
graphic format import or export filters. But they don't have uniform
API. Some have either a GraphicImport or GraphicExport entry point,
and are loaded and used in a uniform fashion from code in
svtools/source/filter/filter.cxx. Others have different API and are
loaded from other places. For instance icgm has ImportCGM, and is
loaded and used by sd/source/filter/cgm/sdcgmfilter.cxx (!).
Svgreader is used for "File -> Open" and then to choose the svg file.
For "Insert -> Picture -> From File", see svgio/source/svgreader directory.
Filter Configuration
The filter configuration consists of two parts, the type definition in
filter/source/config/fragments/types/ and the actual filter definition
in filter/source/config/fragments/filters/.
Each file type e.g. text file should be represented by exactly one type definition. This type can then be referenced by several different filters, e.g. calc text, writer text.