For numeric types, they are made unified templates. In many cases,
gotos were dropped, and the code was streamlined. Hopefully, this
would make it at least a bit manageable.
Change-Id: I63154d61fa6629d1431157ac382ec758f4f50074
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186234
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
At least, CppunitTest_basic_macros CPPUNIT_TEST_NAME=Coverage::Coverage_Iterator
(which exercises it in basic/qa/basic_coverage/test_declare_from_dll.bas)
succeeds.
Change-Id: Ife90d5b84d5fb7bb4948cfeaf48180a6929a1dff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166695
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
1. The regex must match the whole input. Thus, the ^ and $ metacharacters
must be replaced with \A and \z, which only match beginning and end of
input, not any line start / end.
2. The * and ? metacharacters of LIKE must match newline character; thus,
search flags must include UREGEX_DOTALL. To avoid changing TextSearch
implementation, I use icu::RegexMatcher directly.
The direct use of icu::RegexMatcher also allowed to simplify the code by
calling icu::RegexMatcher::matches method. This may perform better than
general-purpose utl::TextSearch::SearchForward.
Change-Id: I75776498b36f236da294462362ed5b36ed8cdf68
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165700
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
since:
commit 9cc8457abc
Date: Fri Dec 15 23:09:19 2023 -0700
tdf#128122 Updated BASIC CCur to reuse SvNumberFormatter
LibreOfficeOssFuzz.conf has --enable-ld=gold and that will just
crash on an unresolved symbol without any explanation, but building
without will give something useful, e.g.
sbxcurr.cxx:(.text._Z14ImpGetCurrencyPK9SbxValues[_Z14ImpGetCurrencyPK9SbxValues]+0x89f): undefined reference to `SbiInstance::GetNumberFormatter()'
/usr/bin/ld: sbxcurr.cxx:(.text._Z14ImpGetCurrencyPK9SbxValues[_Z14ImpGetCurrencyPK9SbxValues]+0xbf7): undefined reference to `SbiInstance::PrepareNumberFormatter(unsigned int&, unsigned int&, unsigned int&, o3tl::strong_int<unsigned short, LanguageTypeTag> const*, DateOrder const*)'
Change-Id: I4b555760a609ec04fd85f7ba9c198a3d2ac712c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161294
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Simply include the global transliterator in all builds.
Regression from commit de81c2545a
("Related: tdf#144245 Optimize case-insensitive handling").
Change-Id: Ica1c6e5d67c8458f9977f2ff87d9594a43b4cff2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132517
Tested-by: Jenkins
Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
...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.
1c9a40299d "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 1c9a40299d):
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>
... 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>
When not using scripting, there were a number of
unresolved symbols. First aproach did not work, so this
commit is the more extensive.
Change-Id: Iaf78bde10d9a43862d58d1aa8f46b14aa075eddb
When building without scripting a couple of
functions were undeclared, to solve that
source/runtime/runtime
source/classes/sbintern
were moved so they also compile in building
without scripting
Change-Id: I908fee3caf8376d70ed286c17085d6b8a700ae75
* all .ui files go from <interface> to <interface domain="MODULE"> e.g. vcl
* all .src files go away and the english source strings folded into the .hrc as NC_("context", "source string")
* ResMgr is dropped in favour of std::locale imbued by boost::locale::generator pointed at matching
MODULE .mo files
* UIConfig translations are folded into the module .mo, so e.g. UIConfig_cui
goes from l10n target to normal one, so the res/lang.zips of UI files go away
* translation via Translation::get(hrc-define-key, imbued-std::locale)
* python can now be translated with its inbuilt gettext support (we keep the name strings.hrc there
to keep finding the .hrc file uniform) so magic numbers can go away there
* java and starbasic components can be translated via the pre-existing css.resource.StringResourceWithLocation
mechanism
* en-US res files go away, their strings are now the .hrc keys in the source code
* remaining .res files are replaced by .mo files
* in .res/.ui-lang-zip files, the old scheme missing translations of strings
results in inserting the english original so something can be found, now the
standard fallback of using the english original from the source key is used, so
partial translations shrink dramatically in size
* extract .hrc strings with hrcex which backs onto
xgettext -C --add-comments --keyword=NC_:1c,2 --from-code=UTF-8 --no-wrap
* extract .ui strings with uiex which backs onto
xgettext --add-comments --no-wrap
* qtz for gettext translations is generated at runtime as ascii-ified crc32 of
content + "|" + msgid
* [API CHANGE] remove deprecated binary .res resouce loader related uno apis
com::sun::star::resource::OfficeResourceLoader
com::sun::star::resource::XResourceBundleLoader
com::sun::star::resource::XResourceBundle
when translating strings via uno apis
com.sun.star.resource.StringResourceWithLocation
can continue to be used
Change-Id: Ia2594a2672b7301d9c3421fdf31b6cfe7f3f8d0a
In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Feature test macros that govern conditional compilation should be
defined in config_*.h include files, not on the compilation command
line.
Change-Id: I40575a4762fd2564f10927b6f38a112dd9f9a3d7
I had to fix some source files because of macro redefinitions and such stuff.
Small modules like basic have a great win, too:
make basic.clean && time make basic:
with w/o
pch pch
accessibility 23s 1m59s
basctl 30s 1m42s
basic 56s 1m35s
comphelper 23s 51s
editeng 48s 2m04s
forms 40s 1m40s
unotools 19s 38s
sd 3m37s 4m33s
Change-Id: Id24cdcddbe2ff64820b42266325c25af1355558f
Reviewed-on: https://gerrit.libreoffice.org/9293
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
...that had originally been introduced to catch DBG_ASSERTs during smoketest,
but since made effectively unused when basing DBG_ASSERT on the sal/log.hxx
functionality, and obsoleted by the ongoing clean-up of using true assert where
appliable.
Change-Id: I2fb4f5d0873d29595b178057f83c1404c0085575
ListBox appearance fixed at the borders:
a) bottom: it it placed over the current line (not under)
b) right side: listbox's right side is adjusted to the window's right side
Coed fixes:
CodeCompleteOptions now intializes itself from the configuration file BasicIDE.xcs
Added a checkbox for enabling extended types in the options dialog.
Cursor is visible when the listbox is active.
Fixed the small issue when deleting a character.
Change-Id: I68b80143de245cebfce65cdd8af37ea4694aa81b
WARNING: cache implementation gives a link error to it's methods.
Created the cache called CodeCompleteDataCache in file include/basic/codecompletecache.hxx
This class should replace the std::vector< CodeCompleteData > int file baside2b.cxx
When issuing command "make basic", it compiles fine, but, when "make basctl", it gives a link error (ld returned status 1) to CodeCompleteDataCache's methods.
Change-Id: If78c6533b7fb5653cc459d22b80c98d097b886eb
Insert basic/source/runtime/step[012].cxx into
basic/source/runtime/runtime.cxx.
Follow-up to https://gerrit.libreoffice.org/#/c/3373/ .
In many cases the sources for some class have been split up into several
source files, typically suffixed with a number 0, 1, 2 etc. Presumably this
has been done because some compiler years ago was not capable of compiling all
the source for that class at one time, or some other no longer relevant
reason.
It would be nice to get rid of this convention, so that clever compilers have
a better chance of noticing unused private fields in a class, for
instance. Just combining the source files in question into one source file and
removing the old source files from git leads to a discontinuity in version
control history. But the consensus seems to be that this is not such a big
deal.
I picked these sources just because they happened to be the first ones I came
across when looking for files called *0.cxx.
Change-Id: Ia7e8ece9a4374721bbcce6b0e2aba5721436faae
Moved portions from module i18npool, all of former i18nisolang1 library
that now is i18nlangtag. Included are languagetag, isolang and mslangid.
This i18nlangtag code is now even used by module comphelper, so
disentangling i18npool and making this an own module was needed to not
create circular module dependencies.
Change-Id: Ib887c3d6dde667403fd22d382310ba5f1a9b0015
- do not use gb_UnpackedTarball_copy_header_files for boost
- adapt the optimization in concat-deps.c for new path
- use boost_headers in all LinkTargets that require it
- add explicit include paths to mysqlc, mysqlcppconn, libvisio, liborcus
Change-Id: I0c43e73ed43cc9d2e6bce8faf55e992d655a0bb9
GUI only takes values UNX or WNT, so it is fairly pointless. One can check
whether OS is WNT or not instead.
Change-Id: I78ae32c03536a496a563e5deeb0fca78aebf9c34
Reviewed-on: https://gerrit.libreoffice.org/1304
Reviewed-by: Peter Foley <pefoley2@verizon.net>
Tested-by: Peter Foley <pefoley2@verizon.net>
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
Naming convention for gbuild methods:
- "add" is used for stuff that is logically a part of the target
(i.e. not registered at the Module, but defined in the target's makefile)
- "use" is used for stuff that is logically a different target
(i.e. it is registered at the Module, has it's own makefile, may be
in a different module than the target)
Nah, these dummy classes would turn out quite complex anyway. Better
to just use ifdefs elsewhere, the number required is not that large.
This reverts commit 6d33801b44.
Work in progress, the dummy class implementations surely still
incomplete and/or might contain methods not actually needed. More
dummy class implementations needed, hopefully not too many
though. Will add also a few ifdefs for DISABLE_SCRIPTING in some key
places in sc and elsewhere to cut down on the need.
Mike Kaganski