aboutsummaryrefslogtreecommitdiff
path: root/source/kok
ModeNameSize
d---------accessibility / source33logplain
d---------avmedia / source33logplain
d---------basctl68logplain
d---------basic / source33logplain
d---------chart268logplain
d---------connectivity68logplain
d---------cui68logplain
d---------dbaccess68logplain
d---------desktop68logplain
d---------dictionaries1754logplain
d---------editeng / source33logplain
d---------extensions68logplain
d---------extras / source33logplain
d---------filter68logplain
d---------forms / source33logplain
d---------formula68logplain
d---------fpicker68logplain
d---------framework / source33logplain
d---------instsetoo_native / inc_openoffice / windows41logplain
d---------librelogo / source33logplain
d---------mysqlc70logplain
d---------nlpsolver61logplain
d---------officecfg / registry / data / org35logplain
d---------readlicense_oo35logplain
d---------reportbuilder / java / org / libreoffice / report / function31logplain
d---------reportdesign68logplain
d---------sc68logplain
d---------scaddins / source33logplain
d---------sccomp / source33logplain
d---------scp2 / source33logplain
d---------sd68logplain
d---------setup_native / source33logplain
d---------sfx268logplain
d---------shell / source / win32 / shlxthandler33logplain
d---------starmath72logplain
d---------svl / source33logplain
d---------svtools68logplain
d---------svx68logplain
d---------sw68logplain
d---------swext / mediawiki36logplain
d---------sysui / desktop34logplain
d---------tubes / uiconfig35logplain
d---------uui72logplain
d---------vcl68logplain
d---------wizards / source33logplain
d---------xmlsecurity68logplain
generated by cgit (git 2.34.1) at 2024-12-24 20:38:31 +0000
'private/mst/sw_redlinehide_2'>private/mst/sw_redlinehide_2 LibreOffice 核心代码仓库文档基金会
summaryrefslogtreecommitdiff
path: root/ure
AgeCommit message (Collapse)Author
2022-02-25Provide unoidl-write also for the SDKStephan Bergmann
...after the new types.rdb format that unoidl-write generates has been used internally since LibreOffice 4.1 in 2013; following up on 6db34b6b33ba8e3b13683efd05df8441b87e9c92 "Directly build UNOIDL .rdb files from .idl files" and its "The legacy tools idlc, regcompare, regmerge, and regview are still contained in the URE or SDK for now." The tools idlc and regmerge are deprecated but still shipped in the SDK for now. The plan is to drop them completely for LO 7.5. odk/examples/ and ure/source/uretest/ are adapted to use unoidl-write instead of idlc and regmerge: * unoidl-write does not use a C preprocessor and the # directives in .idl files, it supports reading a single .idl file (containing an arbitrary number of declarations) or a directory tree where each directory corresponds to a UNOIDL module of the same name and each .idl file contains the declaration of the (non-module) UNOIDL entity of the same name. For some of the odk/examples/, that required moving individual .idl files into sub-directories named after the respective modules. In odk/settings/std.mk, definitinos of IDL and REGMERGE have been replaced with a new UNOIDLWRITE. * unoidl-write always enforces reserved UNOIDL identifier restrictions (see 04af4e4f55f3ef319a78edd4d0109e2e7eba90b6 "[API CHANGE] Fix all bad UNOIDL identifiers across offapi" and 620179240670bd00f60555f1f5c5b0268492f97c "Enforce the UNOIDL identifier scheme") (which idlc only enforced optionally with -cid -we). That required renaming "my_module" in odk/examples/DevelopersGuide/Components/CppComponent/. * The new types.rdb format is not compatibly with LibreOffice < 4.1. Clients generating extensions containing such files are advised to use appropriate LibreOffice-minimal-version elements. Change-Id: I1a248fd96e86ecbf407f829bc100d44bfe7f4e7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130533 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-02-24Update README lists of URE dynamic librariesStephan Bergmann
...after 3a009c427fc04c0a1a100f5f04516cedd1f6f118 "fdo#60698: Merge all libs of io..." and 475e4b477c6d7ae114c3ae51ba4872882af67a68 "Move i18nlangtag lib to URELIB" Change-Id: Idf46dc1a8fa80417aac091e907ba54e83f9099e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130489 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-08Don't install the uno script when uno is not buildJan-Marek Glogowski
... move it into cpputools and rename ure/Package_install.mk to ure/Package_ure_install.mk, to match the module name. Follow up from commit 92a90cf5ccb998d2fcc77a62bb971534e410cdec ("Don't build the static uno binary"). I missed that hunk in a larger patch, because the script was in a different module, then the binary. Change-Id: If7f3152be9567cf84be176d3fedefbcd5ad8d387 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128138 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-10Generally determine Rdb content from gb_*_set_componentfile callsStephan Bergmann
...instead of by listing the content somewhat redundantly in the Rdb_*.mk files, to avoid duplication of logic for components that are only built conditionally (and thus should only be included conditionally in the corresponding Rdb). To achieve that, add an "rdb" parameter to gb_ComponentTarget_ComponentTarget (and to the gb_*_set_componentfile macros that internally call gb_ComponentTarget_ComponentTarget), which is used to make the appropriate gb_Rdb_add_component call internally from within gb_ComponentTarget_ComponentTarget. (As a special case, gb_CppunitTest_set_componentfile shall not call gb_Rdb_add_component, as that has already been done by the corresponding gb_Library_set_componentfile call, so allow the gb_ComponentTarget_ComponentTarget "rdb" parameter to be empty to support that special case.) Most Rdb_*.mk files are thus mostly empty now. One exception is i18npool/Rdb_saxparser.mk, which duplicates some of the Rdb_services content as needed during the build in CustomTarget_i18npool/localedata. 1c9a40299d328c78c035ca63ccdf22c5c669a03b "gbuild: create services.rdb from built components" had already tried to do something similar (in addition to other things) under a new --enable-services-rdb-from-build option. However, that approach had four drawbacks that this approach here addresses (and which thus partly reverts 1c9a40299d328c78c035ca63ccdf22c5c669a03b): 1 Rdb_services shall not contain the component files of all libraries that are built. While that commit filtered out the component files that go into Rdb_ure/services (ure/Rdb_ure.mk), it failed to filter out the component files that go into others like Rdb_postgresql-sdbc (connectivity/Rdb_postgresql-sdbc.mk). 2 The code added by that commit to Makefile.gbuild codified the knowledge that there is an Rdb_services, which is brittle. 3 The code added by that commit to solenv/gbuild/Rdb.mk codified the knowledge (for gb_Rdb__URECOMPONENTS) that there is an Rdb_ure/services, which is brittle. 4 Introducing an --enable-services-rdb-from-build option needlessly provided two different ways how the content of Rdb_services is assembled. The changes done here would leave --enable-services-rdb-from-build as a misnomer, as it no longer controls how Rdb_services is assembled. I thus renamed it to --enable-customtarget-components, as that is apparently what it still does now. Change-Id: Ia5e8df4b640146c77421fcec6daa11a9cd260265 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126577 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-31Adapt to cppu-/javamaker's idiosyncratic relative URL notationStephan Bergmann
...which considers an argument containing SEPARATOR characters only as a relative URL (which it then makes absolute relative to osl_getProcessWorkingDir) if it starts with a dot (see convertToFileUrl in codemaker/source/codemaker/global.cxx). (Which isn't an issue for now, as convertToFileUrl leaves the relative path unchanged, which is passed to the unoidl::detail::LegacyProvider ctor in unoidl/source/legacyprovider.cxx and on to store::FileHandle::initialize in store/source/lockbyte.cxx, which makes a relative pFilename absolute relative to osl_getProcessWorkingDir. But it would become an issue when the given type RDBs are changed to the new UNOIDL binary format, as the unoidl::detail::UnoidlProvider ctor in unoidl/source/unoidlprovider.hxx expects an absolute file URL.) Change-Id: If9f66f3e9c20a8416d25989099e6c921520e6a94 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121312 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-17Fix typoAndrea Gelmini
Change-Id: Ib67f29eec54557811eb1136673030249b296289e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120599 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-06-29Revert bogus drop of "rtl::" prefix in external codeStephan Bergmann
partially reverts 6f50961e69406a17d6ec998956a6b33208b1001b "remove more rtl::OUString and OString prefixes" Change-Id: Ic97a6029577533e539e99d64ba73a74e3246f03b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118048 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-19Updated README.md filesHossein
* Updated README.md contents to fix various issues * Fixed source links by using [git:], processed by mkdocs scripts * Added README.md for ios, setup_native, unotest * Fixed issues with "underline" and "less than" sign Change-Id: I3e52a1d3372586c390ee6c42a2ef48bbabc81398 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114248 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-04-07Updated README.md files to represent current code / use Markdown formatHossein
Previously, all of the README files have been renamed to README.md and now, the contents of these files were changed to use Markdown format. Other than format inconsistency, some README.md files lacked information about modules, or were out of date. By using LibreOffice / OpenOffice wiki and other documentation websites, these files were updated. Now every README.md file has a title, and some description. The top-level README.md file is changed to add links to the modules. The result of processing the Markdown format README.md files can be seen at: https://docs.libreoffice.org/ Change-Id: Ic3b0c3c064a2498d6a435253b041df010cd7797a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113424 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2021-03-24Using .md extension/Markdown syntax for modules READMEHossein
Renaming all README files for all top level modules to README.md, applying no content change at this stage to be able to track history of the files. These files should be edited to use correct Markdown syntax later. Change-Id: I542fa3f3d32072156f16eaad2211a397cc212665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112977 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2020-05-06Move all public Java classes to libreoffice.jarSamuel Mehrbrodt
This moves the classes from juh.jar and ridl.jar to libreoffice.jar The goal is to have one single jar (and Java module, will be added later) which developers can include to work with LO. juh.jar and ridl.jar are kept as basically empty jars with libreoffice.jar on its classpath to keep backwards compatibility. This is a continuation of ae855bf48163ff64d94cfc34aff8e37abdb5518d and a preparation to have Java 9 module support. Change-Id: Ifbbfb97f60373d14256e62ae3122913bd17d5bbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91930 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-02-04tdf#117331 Merge jurt and unoil into ridlSamuel Mehrbrodt
jurt.jar and unoil.jar are kept as effectively empty jars, each with a Class-Path: ridl.jar in their meta-inf/manifest.mf, so that 3rd-party code loading them (with or without also loading ridl.jar) will still have access to their content. Conceptually, the UNOIDL entities in unoil.jar (corresponding to module offapi) are not part of the URE, but are now made available by URE's ridl.jar. This should probably not cause problems in practice. At least for now, we seal exactly those packages in ridl.jar that were originally sealed in jurt.jar. Ideally, all of ridl.jar could be sealed now, but that would be mildly incompatible, as it would prevent 3rd-party code from introducing additional UNOIDL entities in the relevant namespaces (even if that is something we do not want 3rd-party code to do anyway). However, some JunitTest_jurt_* define classes in those sealed packages. In the past they got away with that by using gb_JunitTest_use_jar_classset,*,jurt. Instead they now need to gb_JunitTest_use_jar_classset,*,ridl and drop the gb_JunitTest_use_jar,*,ridl. But the former only makes available the classes that are specified in ridljar/Jar_ridl.mk with gb_Jar_add_sourcefiles, not the UNOIDL entities specified via gb_Jar_add_packagedirs. But the tests need the udkapi UNOIDL entities, so introduce gb_JunitTest_add_classpath to let the tests get them explicitly. (Curiously, JunitTest_jurt_uno and JnitTest_jurt_util use gb_JunitTest_use_jar_classset,*,jurt but don't seem to acutally need it; lets leave that for a follow-up clean up.) As a follow-up clean up, relevant files could be moved from jurt/ to ridljar/. Change-Id: I836f4e7bb47fb41f1306e3f223da90dba988eb9a Co-authored-by: Stephan Bergmann <sbergman@redhat.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/84946 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-10-24remove more rtl::OUString and OString prefixesNoel Grandin
which seem to have snuck back in since the great rounds of removals. Change-Id: I85f7f5f4801c0b48dae8b50f51f83595b286d6a1 Reviewed-on: https://gerrit.libreoffice.org/62229 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>