- build both Python2 and Python3 libs by default, and add separate rules
building Python2 and Python.
- use the libraries as built by setuptools, rather than building again
separately
The library can now be installed using CMake v3.0+.
Below is an example configuration.
1. Generate configuation
cmake -H. -Bbuild
-GNinja
-DCMAKE_BUILD_TYPE=Release // The default profile.
-DCMAKE_INSTALL_PREFIX=/usr/local/
-DBUILD_SHARED_LIBS=ON
-DOLM_TESTS=1
-DOLM_FUZZERS=1
2. Build & install the targets
cmake --build build --config Release --target install
3. Run the tests
cd build/test && ctest .
The library can also be used as a dependency with CMake using
find_package(Olm::Olm REQUIRED)
target_link_libraries(my_exe Olm::Olm)
Signed-off-by: Konstantinos Sideris <sideris.konstantin@gmail.com>
Mostly because the standard emscripten docker image does not have
libjson-perl, but python always comes with json. But also because
it was impenetrable.
Change interface to allow the app to get the private part of the
key and instantiate a decryption object from just the private part
of the key.
Changes the function generating a key from random bytes to be
initialising a key with a private key (because it's exactly the
same thing). Exports & imports private key parts as ArrayBuffer at
JS level rather than base64 assuming we are moving that way in
general.
Change the interface again, hopefully this time a bit more normal.
Now we wrap the emscripten module completely and just expose the
high level objects.
The olm library export is now imported as normal (ie. returns
a module rather than a function returning a module) but has an
`init` method which *must* be called. This returns a promise
which resolves when the module is ready. It also rejects if the
module failed to set up, unlike before (and unlike the
promise-not-a-promise that emscripten returns).
Generally catch failures to init the module.
