Convert code like
aStr.compareToAscii("XXX") == 0
to
aStr.equalsAscii("XXX")
which is both easier to read and faster.
Change-Id: I448abf58f2fa0e7715dba53f8e8825ca0587c83f
Convert code like:
0 == aStr.compareToAscii("XXX")
to
aStr.equalsAscii("XXX")
which is both clearer and faster.
Change-Id: I2e906d7d38494db38eb292702fadb781b1251e07
... to set up a fake command line. This is used from pyuno, when
invoked from the "python" executable as "import uno".
On WNT there is an API to get the actual command line, so just use that
even in the "fake" case; on UNX just fake something up.
Just for the record the whole osl_setCommandArgs() is called exactly once
assumption should work out _unless_ there is a program that uses SAL_MAIN
_and_ does a python-level "import uno" _before_ it wants to create a
python-based UNO service (via pyuno_loader::CreateInstance), since
pyuno already takes care to call Runtime::initialize() at most once.
Change-Id: Ifd23de733ea3e6b694d46ab039b6aa4fd3e7fc1b
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Easy to trigger the assert in osl_getCommandArgCount(), just
run instdir/*/program/python and "import unohelper".
Avoid that by setting up a fake command line, hopefully
nobody expects to be able to give relevant args to python...
Change-Id: I0df6c23d6ecbb3c2bce81a9d5bcecdcb1729ddbb
Add backwards compatibility support for Python 2 to the earlier
change in fdo#66025 to improve import error handling under Python 3.
Change-Id: I47bf8ef255c4c2a3e4a2754414977aaa8ed32483
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Had been totaly broken by the recent changes. (Which is fine, it is
just an experimental hack anyway, I am not sure whether it will ever
be used in anger. Just a pet peeve of mine, I dislike seeing
libraries, configuration files, resources etc mixed together in one
"program" folder, especially on OS X, where the convention is to have
app-specific dylibs and frameworks in "Frameworks", and resource files
in "Resources". But this is not any requirement as such; there are
apps in the Mac App Store that blatantly "break" this convention.)
Basically, replace uses of gb_PROGRAMDIRNAME and
gb_Package_PROGRAMDIRNAME with more specific LIBO_FOO_FOLDER, which
for normal builds all expand to the same "program" anyway.
Change-Id: I16c2b3351caa00e251e229aafbccb8346042d3c1
Add more FOO_FOR_BUILD variables and some gb_Foo_for_build functions.
Get rid of gb_INSTROOT and gb_DEVINSTALLROOT, just use INSTROOT.
Change-Id: Iee531b02d14fae41edb68ad589a5dec829a60255
Putting it in a subdirectory on solver is no longer necessary since
python3 started delivering to INSTDIR, so lose the crazy naming.
Change-Id: I17e924e5d872768a64f6a3112f1294f3def7120e
Refactor everything to find and link libraries directly in INSTDIR.
- add gb_LinkTarget_get_linksearchpath_for_layer, and use it to set up
-L paths for T_LDFLAGS in such a way that only allowed libraries
can be linked against; i.e. it's not possible to link URE
linktargets against OOO or not-installed libraries
- gb_Library_get_target is now same as the gb_LinkTarget_get_target
(TODO: this needs cleanup)
- since a pattern rule won't work for linking libraries in INSTDIR,
add a separate per-file rule for every INSTDIR lib
- pattern rule can't find link target in the clean target any more
so add a LINKTARGET variable
- disable gb_Library_add_auxtarget, no auxtargets need to be copied
- tweak the call to gb_Library_Library_platform to pass in a path
in sdk/lib for the versioned URE libs
- fix the Library clean target
- add LAYER parameter to gb_LinkTarget_LinkTarget
- adjust platform link commands
- MSVC link command now uses explicit -manifestfile and -pdb
parameters to keep misc. files out of INSTDIR
- remove gb_Helper_OUTDIR_FOR_BUILDLIBDIR
- adjust Extension, CppunitTest, JunitTest, PythonTest, Gallery,
various CustomTargets to search INSTDIR
- remove SDK library symlinks and import libs from odk/Package_lib
- on Mac OS X, put .dylib symlinks into sdk/lib even though those
are not packaged and would be created by the SDK configury;
we need these to be somewhere for linking anyway
- add a (unfortunately cyclic) dependency on Package ure_install to sal
Change-Id: I70d88742f8c8232ad7b9521416275c67b64fe6cf
... by replacing gb_Rdb_install with a separate constructor so the right
target can be registered at the module. There is still an ugly special
case for the ure/services.
Change-Id: I81c004143f201aaf38daca99819888313ee24f49
Introduced gb_INSTROOT, which is the same as $(INSTDIR) except for Mac OS X,
where it is $(INSTDIR)/LibreOffice.app/Contents. Most stuff ends up there (so
most occurrences of $(INSTDIR) have been replaced with $(gb_INSTROOT)), but SDK-
related stuff goes to $(INSTDIR)/$(gb_Package_SDKDIRNAME). (And
GeneratedPackage needed to be made more flexible, to allow for packages that go
into either of those two places.)
For Android and iOS, gb_INSTROOT probably still needs to be set.
The most obvious missing thing yet to make instdir work for Mac OS X is the
instdir/*/LibreOffice.app/Contents/ure/ vs.
instdir/*/LibreOffice.app/Contents/ure-link/ split.
Change-Id: I4478edd27b14c92c96d92d5169bdca3ec50d78f5
Compiler plugin to replace with matching number(), boolean() or OUString ctor,
ran it, few manual tweaks, mark as really deprecated.
Change-Id: I4a79bdbcf4c460d21e73b635d2bd3725c22876b2
Lots of stuff still either ended up in the wrong place, or was looked up from
the wrong place, or both. Fix most cases.
Change-Id: I06ebbce207c219f3cd82b4387dd9b3fdb83420d4
Change all instances of hardcoded "program", "share" etc subfolder names to
use those from <config_folders.h> instead. In normal builds, the end result
will not change.
Change-Id: I91c95cd8e482818be67307e889ae6df887763f53
Switch to __dir__ entry point for introspection as Python 3 dropped support
for __members__/__methods__. This is backwards compatible to Python 2.6.
Module initialization adjusted to complete type setup (needed for tp_dict)
via PyType_Ready.
Change-Id: Ie1f7b9dd4279242de89d009eb7acdc8c786dab8f
Reviewed-on: https://gerrit.libreoffice.org/5375
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
The ImportError raised on an import failure with the uno module loaded
now includes a complete traceback and the original Python exception
message text, combined with the most relevant (nearest to failure if
imports are nested) uno lookup that also failed.
Change-Id: Id968d84d7f09d555a81017a99369beb503d61439
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
... which was obsoleted by commit
c007292ec3eedcf2b1ad673308fa42aad31a7333 and apparently causes breakage
for builds with gb_GCOV=YES.
Change-Id: I27def9a8b4d003bf82c84e55d36ace37dd8532b0
when we try to call PyUNO_callable object that doesn't have __class__ attribute
Change-Id: Ia05f70d70f248d50aa141b09625f7ec50189e1dd
Reviewed-on: https://gerrit.libreoffice.org/4309
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Tested-by: Michael Stahl <mstahl@redhat.com>
...this e.g. changes the error message when trying to register an extension that
contains an (actively registered) Python component but no pyuno is installed
from "Binary URP bridge disposed during call" to a less frightening "The service
com.sun.star.loader.Python cannot be instantiated."
Change-Id: I10f2b36b11395559ee95ce659878222b5ea99c11
