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.
jan Iversen