use 3.7.0.0.alpha0 where possible;
use the suffix "+" in the about dialog to signalize non-release builds
Change-Id: If09c78cd30b10e54c46f737a695e0194039c7efc
Actually I think it should be removed entirely, because dmake already
includes minor.mk directly from solenv, but I do not want to pry into it
right now...
Change-Id: I51520642f4796d722cb2131e91e9e92a82920531
This makefile must be included from other makefiles, which means it must
be delivered first, which does not play so well with gbuild's
all-in-one-process build. Because the version has not changed once since
the library was introduced in 2006, I consider this just an unecessary
complication of already complex build process.
Change-Id: I8304f0e8ef9e59a046b10f423dbe61d75e3fc5c2
This reverts commit 875c9a28f4.
because it doesn't make sense to build the dmake modules
without -fsigned-char and the gbuild modules with -fsigned-char
and we're still got a few bugs where we assume chars are signed
Conflicts:
solenv/inc/unxlngppc.mk
Change-Id: I6ac07fa3ebadd83efd0da1ee69a010b62dfaad59
this removes dmake completely out of the build for migrated modules
build.pl now assumes modules to be gbuild, unless there is a
prj/dmake file
Change-Id: I674a036b182ee13c5ec093e83cb3d38133112d3b
- instead on lots of recursive build.pl modules to iterate through we build all
tail_build up to the requested module inside one tail_build when doing a
"make foo.all"
- advantage: speeding up because getting rid of lots of recursive makes with
artificial module barriers, forcing almost sequential execution: build, link,
unittest with lots of cpu-idling at each module-end
- disadvantage: all shared dependencies of tail_build are now build for a
(sub)module of tail_build. This is transitional as we migrate more stuff into
tail_build and there are good dependencies inside tail_build
- "make foo.all" now only executes slowcheck now for foo, not for all the deps
The code uses exception specifications, so it doesn't make much
sense to have them, but disable them using a gcc option. MSVC
ignores them completely, so this would leave only clang as
the only compiler to enforce them. Either the majority compiler
needs to enforce it at least in dbgutil builds (in product builds
the option can be seen as a kind of NDEBUG), or alternatively
the exception specifications should be removed.
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
