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.
The problem is that make 3.81 does not match pattern rules whose target
ends with '/' against directories.
(regression from 408822b547,
90491a073c)
So use a fake file ".dir" in the respective directory, and try not to
spawn unnecessary mkdir processes by checking for existence via realpath.
This is all quite ugly and should be reverted once support for make 3.81
is dropped.
Also, fix a pre-existing problem of pattern rules with multiple targets
that used to work by accident in Package.mk.
This is necessary for C++ extensions (at least for those from sdext
module), because the manifest needs preprocessing (the extension's name
is platform-dependent etc.)
