stage 2 of replacing usage of various checks for the windows platform
with the compiler-defined '_WIN32' macro
In this stage we focus on replacing usage of the WIN macro
Change-Id: Ie8a4a63198a6de96bd158ecd707dadafb9c8ea84
Reviewed-on: https://gerrit.libreoffice.org/22393
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
This may reduce some degree of dependency on boost.
Done by running a script like:
git grep -l '#include *.boost/scoped_array.hpp.' \
| xargs sed -i -e 's@#include *.boost/scoped_array.hpp.@#include <memory>@'
git grep -l '\(boost::\)\?scoped_array<\([^<>]*\)>' \
| xargs sed -i -e 's/\(boost::\)\?scoped_array<\([^<>]*\)>/std::unique_ptr<\2[]>/'
... and then killing duplicate or unnecessary includes,
while changing manually
m_xOutlineStylesCandidates in xmloff/source/text/txtimp.cxx,
extensions/source/ole/unoconversionutilities.hxx, and
extensions/source/ole/oleobjw.cxx.
Change-Id: I3955ed3ad99b94499a7bd0e6e3a09078771f9bfd
Reviewed-on: https://gerrit.libreoffice.org/16289
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
i.e., after recent "fdo#83753: consider JAVA_HOME and PATH when selecting JRE"
fix, if jfw_findAndSelectJRE found no suitable JRE in
jfw_plugin_getJavaInfoFromJavaHome or jfw_plugin_getJavaInfosFromPath, do not
re-check those locations in jfw_plugin_getAllJavaInfos.
Change-Id: If4e085b4fceff5b2494c7b7b84ac51691dbc78cc
adapted algorithm that selects the Java runtime to be used so that
Java installations associated with the JAVA_HOME and PATH
environment variables are preferred over others
Java installations are now analysed in the following order:
* installation that the JAVA_HOME environment
variable refers to (if it is set)
* Java installations in PATH
* other Java installation (algorithm that was used before)
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Conflicts:
jvmfwk/source/framework.cxx
Change-Id: I3a3ade25322def0c0432b369848f13a6b82034a1
changed type of several parameters of the functions
jfw_plugin_getAllJavaInfos and jfw_plugin_getJavaInfoByPath
from rtl_uString to OUString
Change-Id: I80feb311542e6ccded9f9924f800c75a7e14a1e7
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
...which was effectively unused; there only ever was a single sunjavaplugin that
is now folded directly into jvmfwk. Leaves room for further clean up.
Change-Id: I14dd2a3a09bd1ce9a8c3f5c156628ec11d954a0b
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
...dead at least since c58b07c958 "#i20020#," if
not even since the beginning, 49614181e5 "#i20052#
plugin lib for java framework."
Change-Id: Ic0b35341cb8038ccfe0a2f4f5b758341b9ab13b9
Modules sal, salhelper, cppu, cppuhelper, codemaker (selectively) and odk
have kept them, in order not to break external API (the automatic using declaration
is LO-internal).
Change-Id: I588fc9e0c45b914f824f91c0376980621d730f09
Just sprinkle #ifdef SOLAR_JAVA into the code instead.
In the source for jvmaccess and jvmfwk such ifdefs can be removed as
it isn't compiled unless SOLAR_JAVA.
Change-Id: Ia8614f8bd6d833582d3b79b5fb75f9153fa79606
Done with a perl regex:
s/OUString\s*\(\s*RTL_CONSTASCII_USTRINGPARAM\s*\((\s*"[^")]*?"\s*)\)\s*\)/OUString\($1\)/gms
Change-Id: Idf28320817cdcbea6d0f7ec06a9bf51bd2c3b3ec
Reviewed-on: https://gerrit.libreoffice.org/2832
Reviewed-by: Thomas Arnhold <thomas@arnhold.org>
Tested-by: Thomas Arnhold <thomas@arnhold.org>
Since b699519969 "Drop support for /etc/opt/ure
and ~/.ure from LibreOffice 4" there is no place any more where a plain URE will
store information about a selected JVM, so JavaVirtualMachine::getJavaVM will
go into an endless loop of jfw_startVM -> JFW_E_NO_SELECT ->
jfw_findAndSelectJRE -> jfw_startVM -> ... The solution is to pass the JavaInfo
determined by jfw_findAndSelectJRE into the second invocation of jfw_startVM
(for which the parameter list of the latter needed to be changed), instead of
relying on jfw_findAndSelectJRE and jfw_startVM implicitly communicating that
information via user configuration files.
Change-Id: I5799f04c457e8a849c67ed827dc5e134c6563362
