If anyone wants to do anything with it, there are the sources (but quick
look at ure/source/uretest/Makefile suggests it is dmake, so good luck
with that .-) Maybe it is just another relic of the past that can be
removed?
Change-Id: I44b4a36d89a5617d5dba9e063e8b8b19c1dba240
* Re-use existing settings/dk.mk to tunnel ENABLE_DEBUG into the SDK. Turns out
this was explicitly included in ~all examples Makefiles, but only after
settings.mk where it is now used, so include it in settings.mk now and dropped
it from all the exmaples Makefiles.
* The old settings.mk was apparently confused with using /MT ("link with
LIBCMT.LIB") on cl command line and /MD ("link with MSVCRT.LIB") on link
command line (where it was ignored), and you apparently can't pass both
together to cl, so I settled on /MD (resp. /MDd) now and dropped /MT (resp.
/MTd). No idea if that is exactly right, however.
* Introduced client-facing LIBO_SDK_LDFLAGS_STDLIBS that covers kernel32.lib and
msvcrt.lib vs. msvcrtd.lib on Windows. Adapted examples Makefiles and
/ure/source/uretest/Makefile accordingly. Some examples Makefiles
additionally use msvcprt.lib, no idea whether that still needs to be
addressed.
Change-Id: Ia8d9d177e415abfbaf6f9fa6239f0ef9998868be
Move unoidl functionality into a module of its own, as a prerequisite to use it
in codemaker etc. (This is intended to ultimately remove modules store and
registry, modulo backwards compatibility constraints.)
Change-Id: If5274cbd3a595951e6cf7a9664bc542f01833f38
...instead of the ure executable's obsolte -ro arguments (leading to usage of
deprecated bootstrap_InitialComponentContext with an XSimpleRegistry instead).
The com.sun.star.lang.MultiServiceFactory service is (only) implemented by the
cppuhelper/source/defaultbootstrap.cxx ServiceManager itself, but it doesn't add
itself to its list of know services, so cppmain.cc should not test for it.
Change-Id: Iaaf8d466fe3607ab9bac6aba09396809e53404f3
...had been forgotten in f98379816411f932ccdafede5f9b25c260c17361 "Make
ure/source/uretest work again"
Change-Id: I9175118126124eba4ea750914d588f6c1ccb2604
...since 1628005298923ad15cc78dbad63669b701f5fd04 "Trying to remove the stlport
mention from the code"
Change-Id: I8785274bc2fdc9d97200aea245e1e8182249cde6
The STLport was only built for the benefit of old extensions on platforms that
once used it themselves (Linux x86, Solaris x86 and SPARC, Windows). We
deliberately break such old extensions for LO 4.0 by no longer shipping that
backwards-compatiblity cludge.
Keeps STLport listed in readlicense_oo/ because of
o3tl/inc/o3tl/compat_functionality.hxx.
Also removes GXX_INCLUDE_PATH, as that was only used by STLport (if at all?).
Removes a spurious #define MOVEFILE_REPLACE_EXISTING 0x01 from
l10ntools/inc/helpmerge.hxx that was once added with
854812584862d0609b695682d2bfea2667d75c00 "INTEGRATION: CWS extensionl10nfix01
(1.11.6); FILE MERGED: 2008/06/26 13:56:03 ihi 1.11.6.1: #i90987# windows rename
-> MoveFileEx" but now starts to cause trouble on Windows. Also disables
warning C4005 about redefinition of WB_LEFT/RIGHT macros (defined in both
tools/wintypes.hxx and the Windows API) in a number of places that include
windows.h -- however the old STLport caused those warnings to not show.
Change-Id: Ie138a219fbbc86fb5aaa7ea0b88cf349935d9829
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
For one, /etc/opt/ure was probably never used by anyone anyway, so meant just
needless file-stats during startup. For another, accidentally created
~/.ure/javasettings_*.xml that later became stale were noted to cause trouble,
so that source is now closed.
For this to work, jvmfwk needs to be silent now if it cannot read/write any
shared/user javasettings_*.xml.
Change-Id: I332b5ebb9549dc6ccf7c99c439d9a3b61aeb5829
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
...at least, Makefile (to be run from within an SDK environment) works again; I
reflected all the relevant changes in Makefile.pln (to be run from no specific
environment) too, but did not actually check the latter
Change-Id: Ie2012d26b3bd59335a0f872bbfc1414cc4f5edc5
Evidently on Windows, the newfangled ucpp handles #include "foo"
differently from #include <foo> and treats it as a relative path, while
the angle brackets always result in absolute paths.
Since relative paths result in infinite rebuilds if make is invoked in a
different directory, don't use #include "foo" in IDL files.
Change-Id: Iedcda3a4be5542389a0be086f14541cda8dc5323
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
Those bootstrap variables now support <XXX>* syntax to include all files (non-
recursively) contained in the directory denoted by XXX. Optional components can
put their data simply into program/services/ and program/types/.
