We still have checks for $(COM) being GCC or MSC in makefiles, of
course. But there is no reason to pass -D$(COM) to compilations.
Checking the built-in compiler-specific macros __GNUC__, _MSC_VER
(etc) is the right thing to do.
Change-Id: Ia961a29ba74e2c4977e5300a92318f38104c6592
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>
...this was a transitional hack to get XML-format service.rdbs in. Now that
registry-based bootstrap_InitialComponentContext is gone, XML-format .rdbs need
only be handled in cppuhelper/source/defaultbootstrap.cxx (so the
textualservices stuff once duplicated to there now effectively moved there).
Change-Id: Ifb93558768095c1b462fe4057ebf8724968cca77
... com.sun.star.comp.helper.RegistryServiceFactory (juh.jar). Superseded by
default bootstrap mechanisms.
An aborting stub for non-inline cppu::createRegistryServiceFactory is left in
cppuhelper/srouce/compat.cxx to avoid having to incompatibly change
cppuhelper/soruce/gcc3.map.
Change-Id: I590e50b8f57e86d4bb3e00d157c9e5907c02f267
...so that 16f856a5ca "Adapt climaker to
cppu::bootstrap_InitialComponentContext removal" does not fail. Starting uno
processes from within the build should thus use URE_MORE_SERVICES/TYPES now,
too.
Change-Id: I0a7cfacc804814a2688e54275ebc3e39540d307c
cppu::createSimpleRegistry, cppu::createNestedRegistry, and
cppu::bootstrap_InitialComponentContext for registry-based type/service
information, superseded by cppu::defaultBootstrap_InitialComponentContext.
Aborting stubs for the three functions are left in cppuhelper/source/compat.cxx
to avoid having to incompatibly change cppuhelper/source/gcc3.map.
Change-Id: I8e714c021c246b15a6e6fb7f25d754dceff17c8a
This changes all generated API headers (.hpp and .hdl) to use a
namespace alias 'css' instead of the pointlessly long com::sun::star
Makes the change in cppumaker & associated tools, adds a global
namespace alias definition in sal/types.h, and removes a kiloton
of local, now pointless-to-harmful versions of that alias from all
over the code.
Change-Id: Ice5a644a6b971a981f01dc0589d48f5add31cc0f
...as there are typically no direct calls to it anyway. What is apparently
needed is to decorate the cppumaker-generated headers instead:
* cppumaker obtains deprecation-information from the documentation strings in
.rdb files. As these are normally generated by idlc without documentation
included (no -C), idlc got changed to nevertheless contain documentation
consisting of just "@deprecated" in this case, to allow to easily tunnel this
information to cppumaker always.
* The mechanism of parsing for "@deprecated" in documentation strings is
somewhat crude, of course.
* For now, cppumaker only decorates C++ functions that correspond to UNOIDL
interface attributes and methods. More should be possible (but, e.g., being
able to decorate a complete C++ class corresponding to a deprecated UNOIDL
interface type depends on whether all platforms would accept
SAL_DEPRECATED_INTERNAL at the same position in a C++ class declaration.
* This could also be extended to other languages than C++/cppumaker.
* Always using SAL_DEPRECATED_INERNAL instead of SAL_DEPRECATED for decoration
is to keep things simple and our codebase working. Improvements are possible
here, too, of course.
Change-Id: Ia2917892f780d477652e4cd9f286588a6898c3f5
There are basicically two classes of cases:
1) Where the code is for obscure historical reasons or what I see as
misguided "optimization" split into a more libraries than necessary,
and these then are loaded at run-time. Instead, just use direct
linking.
2) Where dynamic loading is part of the functionality offered to some
upper (scripting etc) layer, or where some system-specific non-LO
library is loaded dynamically, as it is not necessarily present on
end-user machines. Can't have such in the DISABLE_DYNLOADING case.
Change-Id: I9eceac5fb635245def2f4f3320821447bb7cd8c0
Always link in gb_STDLIBS, except when the library explicitly opts out
with gb_LinkTarget_disable_standard_system_libs.
Change-Id: I489a99114fbfa46d0421a27cf6c7b899dc268a4a
This is such a fatal error that there is probably no point in trying to handle
it, so allow to simplify client code by removing the requirement to check for a
null return value.
Simplified some client code accordingly (modules configmgr and ure, and the code
generated by cppumaker and javamaker).
Change-Id: I51c0b270ec73409374f7439a47ee061407a46e31
removeRdbFiles suffered from a confusion that ImplementationInfo.uri denotes the
corresponding component (.so, .jar, etc.), but not the .rdb file. So removing
an .rdb file silently failed to remove the corresponding implementations, so re-
installing a similar enough .rdb (as typically happens during extension update)
would fail due to duplicate implementation names.
Change-Id: I25d4ff72656c99a3af509eef09e89c18cfd0aabe
Erasing from data_ member maps can destroy contained Implementations, which in
turn releases the UNO objects referenced from there, which in turn can cause
XComponents to dispose, which in turn can call arbitrary code, so must not be
done with rMutex locked. Witness the backtrace at
<https://bugs.freedesktop.org/attachment.cgi?id=65142> linked from fdo#52639
(where this fix appears otherwise unrelated to that issue's main topic).
Change-Id: If55a3841b761ec1d9a0ef61fe54784426c4ee442
...in loadImplementation (instead of using the context the ServiceManager itself
was created with). Otherwise, the handcrafted context containing a fake
theJavaVirtualMachine singleton in install_vm_singleton
(javaunohelper/source/vm.cxx) would not be honored, so that if a Java process
bootstraps native (binary) UNO and from there tries to obtain that singleton, it
would erroneously try to instantiate another JVM instead of using the existing
one. This was a regression introduced with the new ServiceManager and could be
witnessed by test-javanative in ure/source/uretest/Makefile failing.
Change-Id: I58cfbc8cdaea7ee4ab80fac728ea3e85676d69e1
http://lists.freedesktop.org/archives/libreoffice/2012-April/029940.html
The RTL_USING #define (set by gbuild for anything that's not public
API) allows to use such classes simply by their name, without having
to use the namespace or do explicit using rtl::OUString (which half
of the sources do anyway).
Change-Id: I7edaf12cd278489cdc1d5ff782f0a86361c13c0a
...as some client code catches just the former and thus fails now. (This was a
regression introduced with the recent cppuhelper/source/defaultbootstrap.cxx.)
Change-Id: I8306797f8331d894ab4e7695478e3824e9f79197
