msvc2008 now prints out a lot of warnings, probably a result
of the recent -Wnon-virtual-dtor changes where msvc does not
understand the protected dtor actually makes the code to be ok
...which has the necessary features to support it.
Change a lot of classes to either contain a protected non-virtual dtor
(which is backwards compatible, so even works for cppumaker-generated
UNO headers) or a public virtual one.
cppuhelper/propertysetmixin.hxx still needs to disable the warning, as
the relevant class has a non-virtual dtor but friends, which would still
cause GCC to warn.
Includes a patch for libcmis, intended to be upstreamed.
Since OString already has a ctor accepting const char*, I cannot
find out a way to distinguish string literals other than using
a template, otherwise const char* somehow takes precedence
(all of gcc, clang, msvc). But the template requires
the Substitution Is Not A Failure Idiom to actually create
only wanted instances. And the compiler can try evaluate
the OString ctor as a possibility when comparing an int to
an anonymous enum, and anonymous enum as a type without linkage
cannot be a template argument before C++11. SFINAE should still
work, but not with gcc older than 4.0.2 (which we right now
use only on macs). So for that case disable the string literal
ctors, which means macs will have one extra strlen call,
and also that embedded \0's in string literals will be
inconsistent. The tiny performance problem shouldn't matter that
much and will eventually go away, the \0 problem should not
matter, since before string literal ctors were introduced
\0's had not been included anyway unless RTL_CONSTASCII_STRINGPARAM
was used. So we should be safe and when removing the CONSTASCII
macros \0 cases should be handled by explicitly mentioning
the length.
It's too small to justify standalone existence.
We can accumulate i18n things we link to directly into
i18nutil and rework i18npool uno implementions in terms
of thin wrappers over i18nutil and prefer linking to
i18nutil internally and leave the uno forwarders for
use by external components and scripting
We don't use it in gbuild/platform/IOS_ARM_CCC.mk either. Need to be
consistent or we get linker warnings. Should we use it? Probably it
isn't that important for iOS?
...by allowing our special @___... tokens anywhere within an install name,
so that external modules can configure --prefix=/@___... etc. This removes
the need for the special extshl and EXTRPATH=LOADER. Also, a new
OUT2BIN_NONE can be used for external modules where the generated libraries
need the default EXTRPATH=OOO, but generated executables are only used
during the build and such need RPATH=NONE.
"localize" is now directly a C++ program w/o wrapper script. Also,
its command line has changed slightly, taking the source root as
explicit argument (instead of implicitly as cwd).
Instead of introducing a global variable, use the already existing
saved android_app pointer in lo-bootstrap.c, and just add a function
to retrieve it from there. Store it in the AndroidSalInstance.
Reanme osl/detail/android.h back to android_native_app_glue.h, which
is the name of that file in NDK/sources. "android.h" sounded to me too
grand, as if it was some universal Android header. But if we do start
to modify the android_native_app_glue stuff heavily, then it indeed
makes sense to call it something else. Until then, revert also some
whitespace changes to android_native_app_glue.c for it to be as close
as possible to the "upstream" one in the NDK, for clarity.
Instead of introducing a global variable, use the already existing
saved android_app pointer in lo-bootstrap.c, and just add a function
to rettrieve that.
Reanme osl/detail/android.h back to android_native_app_glue.h, which
is the file from NDK/sources that it is. "android.h" sounded to me too
grand, as if it was some universal Android header. But if we do start
to modify the android_native_app_glue stuff heavily, then it indeed
makes sense to call it something else. Until then, revert also some
whitespace changes to android_native_app_glue.c for it to be as close
as possible to the "upstream" one in the NDK, for clarity.
