Hi all, I've tried to outline the requirements and my vague plans as I understand them for building deltachat-core. I hope it clarifies a little what I'm trying to do an hopefully people can point out parts where this isn't quite right or they have other concerns. So these are the various scenarios I think need to be supported and how I'm thinking of approaching them: ** Linux - All dependencies are available. - System dependencies get used - Note that currently netpgp is an exception, it's objects should always be bundled into libdeltachat.so - Distros should use this. - shared libdeltachat.so gets built - installed into prefix (/usr/local by default) - Some dependencies are missing - Available system dependencies get used - Missing system dependencies get built - shared lib - installed into prefix (/usr/local by default) - with normal soname/soversion - thus needs to be a reasonable standard incarnation of the dependency - note that boringssl is an exception, it should not be installed as a shared lib on the system as it's libcrypto.so and libssl.so are not API/ABI compatible with the system libs. - note that currently netpgp is a similar exception - shared libdeltachat.so gets built - installed into prefix (/usr/local by default) - Portable/monolithic library - low priority - all dependencies' objects bundled in libdeltachat.so - only needed symbols - libdeltachat.so does not have any other dependencies ** Android - zlib is only available dependency - link with this as shared lib - Build static archives of all other deps - including boringssl, i.e. libcrypto.a, libssl.a - build libdeltachat.a - Does not include any objects of the dependencies (aka no monolith) - Android.mk - needs meson/ninja to produce all .a files first - lists the .a files as input in .mk files - normal android build for here - only needed symbols are included in final app ** Python bindings/wheels - Source install needs normal Linux scenario first - wheel - on manylinux1 build container - normal linux scenario install - libs bundled in wheel with RPATH pointing to them ** Node bindings - Use libdeltachat.a - Thus also all .a files of dependencies - Needs to point to .a files (+ headers) of any dependencies already in node, e.g. OpenSSL. ** Desktop build - ?? - Uses libdeltachat.so? ** Mac - Mostly like linux scenarios - Likely fewer available deps - .so -> .dylib ** Windows - No system dependencies - All dependencies need to be built as .dll files - libdeltachat.dll needs to link to them - rpath equiv? - ldconfig equiv? ** iOS - Similar to android? - meson/ninja need to produce all .a files - these get linked into the app ** General concerns - Various scenarios, result in using BoringSSL symbols bundled in libdeltachat.so. When used these could result in conflicts if whoever links libdeltachat.so already happens to link against OpenSSL. This could be alleviated by hiding the BoringSSL symbol visibility, but this is uncertain. Please let me know what I got wrong and what I missed. Or any other feedback, like the whole approach handling all dependencies with meson is wrong etc. Thanks, Floris