Age | Commit message (Collapse) | Author |
|
…by a simple/static $(gb_CustomTarget_workdir)/foo
The build system has a lot of overly complicated leftovers from when it
was introduced and had not only deal with split repositories but also
had to coexist with another buildsystem. Along with lots of copy'n'paste
along the years the makefiles became hard to grasp for newcomers with
all our calls and evals.
As a first step to streamline that, the macros from TargetLocations that
simply prefix a static path to the argument (and similar of the same
kind) are a natural pick before simplifying the rules themselves/getting
rid of a bunch of eval statements.
Change-Id: Ia06dbbcd5d1994755a2ff05b84f72ccbc4e3cab5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167005
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I927434290b02b6cc0386b1e0038cd8385a762249
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166996
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Tested-by: Jenkins
|
|
...by using UnoInOutParam in all cases. Some types whose Embind mappings don't
employ any smart pointers (like any and sequence) would have worked directly
with pointers, but others (like string and type) would have caused Embind errors
at runtime. So consistently use UnoInOutParam in all cases (and generate
bindings for all the used cases in embindmaker).
Change-Id: If26551bf4e99d10748aec1597d6e99f994dfd86e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166854
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Idb1457933a784b5ee4364e435d439f544ae28013
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166653
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
(the types that are meant to be passed directly by pointer will need more
thought, to make them actually work)
Change-Id: Ia0f2e6f5335fad1140629477e89fc96121c2927e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166318
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
$equals was the last remaining special $... method that we added to the UNO
interfaces, and it looks better anyway to turn it into a symmetric free function
(that can be called with null for either argument) that is actually independent
of specific interface types
Change-Id: I22a1d08b8b15a0ed2dd37fa9fbc95f568641dec3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166317
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...which are needed at compile time (the emscripten::class_<T> ctor always
records the address of emscripten::internal::raw_destructor<T>, even in cases
where it never calls it; and raw_destructor internally calls delete, but the
dtor of the UNO interface types is protected) but not at runtime (as those UNO
interface types are only accessed through css::uno::Reference smart pointers)
Change-Id: I09e4f258f8dfc0fc53c0fe7210c7f709d86be176
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166304
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
The existing code had two issues: For one, e.g. calling a function that
returned a null interface reference mapped that to JS null, while querying an
object for a non-supported interface via `new css.uno.X...(y)` mapped that to
an "empty" JS object instead. (So checking for a non-null reference needed to
be done as either `x !=== null` or as `x.is()`, depending on context.) And for
another, while calling $is() on a non-"empty" object worked fine, it failed on
such an "empty" object (as the Embind internals of that object lacked the $$
property).
So change the querying mechanism from the `new css.uno.X...(y)` constructor to a
`css.uno.X....query(y)` function call syntax, which now returns JS null when
querying for a non-supported interface. (And drop the broken $is method.)
Change-Id: I8fa488ab2892423f2a461d9b72db47e1d4df3b8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166255
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I8592466b96406a1658d0a5a1b961142f862a9e4d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166290
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
(If throwUnoException directly took a css::uno::Any argument, JS client code
would need to create one with `new Module.uno_Any(...)` and call .delete() on
it, but there is no place where it could call .delete(), so make
throwUnoException take two arguments instead and assemble the css::uno::Any on
the C++ side.)
Change-Id: Iae4ae6af804354d5cf752115e272b79d61427440
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166253
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...now that we have uno_Any get() since 8428368d79118f1d0e09615c5d2b92065b8838d4
"Improve Embing'ing of UNO Any somewhat"
Change-Id: I06572e1ca152117c5c93a1552e50b1399af84780
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166244
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Given the reasoning in 0957ee9f5d379c80fca4027c187b471118d0490d "Embind: No need
for $query", those sharing_policies appear to be (solely) about upcasting of
those smart pointers, and css::uno::Type doesn't involve any class hierarchies,
so NONE ("no upcasting", in genericPointerToWireType in Emscripten's
src/embind/embind.js) appears to be the best match here.
Change-Id: I74b74d3c31cc17a7fd0a6d072160316e60884557
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166160
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...to "upcast" from css::uno::Reference<T> to base
css::uno::Reference<css::uno::XInterface>. My understanding now is that due to
the sharing_policy::INTRUSIVE we specify for
emscripten::smart_ptr_trait<css::uno::Reference<T>>
(include/static/unoembindhelpers/PrimaryBindings.hxx), Embind can internally
"upcast" from a css::uno::Reference<T> to a base
css::uno::Reference<css::uno::XInterface> by just treating the encapsulated raw
pointer of type T* as a raw pointer of type css::uno::XInterface* (see the use
of that sharingPolicy in genericPointerToWireType in Emscripten's
src/embind/embind.js; though documentation of that Embind sharing_policy is
rather poor).
Change-Id: I6ed60a9c94af6aba6fc6119bf644da7f507a997f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166142
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I3a8bf5986b91b886547cfe57e49275f7c79ddc11
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/166020
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I0f6a4ac0910c83d572e2b2e39e8dcea0470517cb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165818
Tested-by: Jenkins
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
|
|
Sentence about Emscripten was probably obsolete since around commit 12a6b57c
Change-Id: Ide59154439f8a069c2dbd58420c1c93844790a79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165754
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
...that had been added there accidentally in
27ceca1996809c0f9390d1e9fb95dc7436ef1acf "Rework the Embind mapping of UNO
interfaces"
Change-Id: I390e4b694e95d665f7bc3d62b0f7ba2c887041bb
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165796
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...which failed with
> error: instdir/program/types/offapi.rdb does not exist
Change-Id: Ie9932960f6e0f6d76070dcdaef792764ac55f51b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/165048
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I43d924126f4d34e0efbcea61dd5f4bd9be235426
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164650
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I1b2167e261f1020b228f8ca2618c7f0009ca1d3d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164646
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Iac5ac8de7bfb19b90d54edc6f4b791d8c0e98977
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164594
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...taking a full UNO Type instead of just a UNO Type class (so that it will be
able to construct Any containing sequence, enum, struct, exception, and
interface, in later steps); moving the Type argument first (as that looks more
natural), and renaming from Any to uno_Any (in line with the other uno_Type,
uno_Sequence_..., etc.)
Change-Id: I154681c4b9187f5f5d037d503652fe7bcd41adcd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164593
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I99d3322afc7876c37a7ace016c1c6af691f28406
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164591
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Id93d7f48dedb362206828b5e3bd946525f95ea77
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164590
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ia56439e0e99c193c7cc56676677df2c671278e24
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164554
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...so one can write foo.$equals(bar.$query) to check for UNO object equality
Change-Id: I727386e833507c86573cf033a1364ff145ed31ee
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164544
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I5c53cb1d244731dac8f9e3f4797a7a155b9a9afa
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164541
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...where it failed with
> In file included from static/source/unoembindhelpers/PrimaryBindings.cxx:13:
> In file included from ~/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/bind.h:23:
> ~/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/val.h:226:20: error: assigning to 'void *' from 'const void *' discards qualifiers
> 226 | cursor->w[0].p = wt;
> | ^~
> ~/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/val.h:248:3: note: in instantiation of function template specialization 'emscripten::internal::writeGenericWireType<const void>' requested here
> 248 | writeGenericWireType(cursor, BindingType<First>::toWireType(std::forward<First>(first)));
> | ^
> ~/emsdk/upstream/emscripten/cache/sysroot/include/emscripten/val.h:256:5: note: in instantiation of function template specialization 'emscripten::internal::writeGenericWireTypes<const void *>' requested here
> 256 | writeGenericWireTypes(cursor, std::forward<Args>(args)...);
> | ^
> static/source/unoembindhelpers/PrimaryBindings.cxx:309:56: note: in instantiation of member function 'emscripten::internal::WireTypePack<const void *>::WireTypePack' requested here
> 309 | emscripten::internal::WireTypePack argv(self.getValue());
> | ^
see the comment at
<https://github.com/emscripten-core/emscripten/commit/0f83fd40533248cce42464e1b9b586281202f247#r139443236>
"[Wasm64] Fix embind with addresses over 4gb (#20071)"
Change-Id: I1f472e9dc57b3abfbe1ba8a0f3a3bd70c1c484f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164463
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...to what is known-working at allotropia. (Also, emsdk --embedded option is
redundant since
<https://github.com/emscripten-core/emsdk/commit/3e9f04d467ba300b43fc40dab657c56f39751c96>
"Remove support for non-embedded mode".)
Change-Id: I7d3f3b72f131301ddc92fcf22503b575f30e7086
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164464
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ief3cdebc1ee7c7b9f012741c9db8637dba9bbd07
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164433
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I5b81ad3d5f1351062aef43105ea7ec4678045a90
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164360
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...which taps into the internals of emscripten::val, which is based on
std::type_info identifiers, so we need an additional statically-built mapping
between UNO (enum, for now) types and std::type_info
Change-Id: I9fc1ff33fe31a1e1052504905de446ed2193e014
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164359
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I82e38ac815765b62601076cf61745fe9889451b3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164358
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...which should be rare enough in practical use that it should be sufficient to
only have toString-functionality for instances mapped from C++ to JS, but no
constructor for new instances on the JS side. (The natural choice for the
latter would be a mapping of the C++
> inline Type( TypeClass eTypeClass, const ::rtl::OUString & rTypeName );
constructor, but which requires a mapping for the css::uno::TypeClass UNOIDL
enum, which is only provided "later" through CustomTarget_static/unoembind, so
would at least conceptually be a bit dirty.)
This Embind mapping treats css::uno::Type as a smart pointer for the underlying
typelib_TypeDescriptionReference, to benefit from the fallback garbage
collection (in more recent Emscripten versions, at least) for smart pointers,
obviating the need to call .delete() on each instance mapped to JS.
Change-Id: Ic113967c264c28641dfd1fe159012c85519f4a9b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164140
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I26ddbfb8b6742d816290d122d22c3c6c3ceabcc0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164143
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
The constants are only reflected directly as JS values in the generated *.js
file. Reflecting them via emscripten::constant in the generated *.cxx did not
work well: Most importantly, emscripten::constant (and its underlying
_embind_register_constant) coerce all values to double, so UNO (unsigned) hyper
would not survive as JS BigInt, which would then cause e.g.
> console.assert(test.isHyper(uno.org.libreoffice.embindtest.Constants.Hyper));
passing such a (JS number, not BigInt) value into the
org.libreoffice.embindtest.XTest::isHyper method (which expects a UNO hyper) to
fail. (Also, constants of UNO boolean type would be represented as numbers 0/1
rather than as false/true.)
Change-Id: I056db0ccce0bf40eb53728fd439cc74964eb6951
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164097
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...that return the "hierarchical object", rather than setting it as a member of
the passed-in instance
Change-Id: I17ad7dd426114c7979f1ba6edaebe83b43eedfed
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164064
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Upcoming code that changes the Embind'ing of UNO sequences will require
availability of the UNO type manager during that Embind init code, so only call
that after UNO has been bootstrapped (rather than as part of the initialization
of global static data, which is what EMSCRIPTEN_BINDINGS does).
Change-Id: Iba19851ffb82c055dcab10a28a8c1fafa9d2a414
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164065
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
80d3f33876a2ad4ce32d3c6183131984e8c6b5da "Library_embindtest should use
comprehensive InternalUnoApi_embindtest" was an attempt at making type
information about that library available at runtime. Which worked for cases
where code directly called one of the types' cppu_detail_getUnoType function.
But it would still fail for cases where code indirectly wants to obtain one of
the types' information by type name---which is what upcoming code will do that
changes the Embind'ing of UNO sequences.
So InternalUnoApi_embindtest would need to become a UnoApi_embindtest whose
instdir/program/types/embindtest.rdb would be available at runtime. But I'm too
dumb to convince gbuild to create that new UnoApi_embindtest. So instead just
tack the embindtest UNOIDL entities onto the existing UnoApi_udkapi for the
EMSCRIPTEN-ENABLE_DBGUTIL case. (Which requires that the single embindtest.idl
is split into individual per-entity files, sigh.)
Change-Id: Ie189b17213ac5b2de7a61ac5f97a143fa097337f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I267d5a7fa9150b16e9625b36c032fa48199758e8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163937
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...to avoid "GET http://localhost:6931/favicon.ico 404 (File not found:
instdir/program/favicon.ico)" errors in the browser console. The checked-in
static/emscripten/favicon.ico is a copy of
<https://www.libreoffice.org/themes/libreofficenew/favicon.ico>.
Change-Id: Ib40b3f159879cc39244bd81d7fc8a36cc8c7184a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163827
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I4ced49774baafdf620ae167c53794932766aca86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163741
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
It is only built for --enable-dbgutil builds. Load
instdir/program/qt_soffice.html in a browser and see "Running embindtest" in its
console. For now, it only contains a Test singleton with an empty XTest
interface, which is meant to grow additional methods over time.
(The code needs to reside in the unotest rather than in the static module, or
else the wasm build would run into cyclic dependencies.)
Change-Id: I6f65f0c904648a4fd96fc6215c8d59a1544f48a2
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163693
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...that had erroneously been added with 27ceca1996809c0f9390d1e9fb95dc7436ef1acf
"Rework the Embind mapping of UNO interfaces"
Change-Id: I421bf2aa7e9f96ce48b227f6f47058581b64d7b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163692
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: I2e1aa828f194a104d354741518e8cb20015ac276
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163385
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: If881428bf69587ad9067378cde01caa87d56c1a3
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163211
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|
|
...though
> let seq = new Module.uno_Sequence_string(["foo", "bar", "baz"]);
> // ...
> delete seq;
is still ugly.
And Embind only allows for overload resolution by number of parameters, not by
their type, so using the original sequence constructor had to be changed to
> let seq = new Module.uno_Sequence_string(3, Module.uno_Sequence.FromSize);
> seq.set(0, "foo");
> seq.set(1, "bar");
> seq.set(2, "baz");
> // ...
> delete seq;
Change-Id: If26ff4a485ba16b65cf24b6fe729d379c733c473
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163097
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
...so that it has a nicer integration into JS, at the expense of copying data
between C++ and JS
Change-Id: I19af55e8db0c374dd7b0f58f74d1af19214175b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163098
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Change-Id: Ic178737da802e17f87d0b5b09004a847b0fe91be
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162956
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|
|
Ideally, JS code would have a way to create instances of arbitrary UNO sequence
types (to e.g. put them into Anys), but that goes against the static nature of
Embind. So at least register JS support for all those UNO sequence types that
are actually used in the UNO API. (This would cause duplicate failures, though,
if we generated multiple separate .cxx files from embindmaker invocations, with
registration code for the same UNO sequence types.)
(Even more ideally, UNO sequence types could map to JS arrays, and/oror be
garbage-collected on the JS side rather than needing explicit delete(). The
resize/size/get/set interface in unoembindhelpers::registerSequence is modelled
after Embind's emscripten::register_vector.)
Change-Id: Icd38b2e03db442dd613b9222b9bd092f947f7bec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162849
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
|