Rework build

[gkdr]

• Get rid of libtool
• Actually make a build that does not depend on SQLite
• Offer build as shared lib (Shared library #9)

[ghost]

Any preferred storage method?

[gkdr]

No, it's just that I wrote in the README:

While the actual protocol functions do not depend on any kind of storage, it comes with a basic implementation in SQLite.

If someone wants to use something else, they shouldn't need the SQLite dependency.
I just think that most applications already have some sort of data storage they would like to continue using.

Since the fuctions in libomemo,c do not depend on storage functions, this should just be an additional makefile target. I just have to remember to do it.

[fortysixandtwo]

Would you be open (I think it came up in another MR) to using a different build system?
While I do like the simplicity of Makefiles using something a little more sophisticated could be nice.

I raise this point because I came across an issue with crosscompiling to aarch64

E: libomemo-dev: triplet-dir-and-architecture-mismatch usr/lib/x86_64-linux-gnu/ is for amd64
E: libomemo0: triplet-dir-and-architecture-mismatch usr/lib/x86_64-linux-gnu/ is for amd64

This is an excerpt from a debian build for arm64 packages (used f.e. on the pinephone or Librem5) http://crossqa.debian.net/build/libomemo_0.7.0-1_arm64_20210501231231.log

It has been pointed out to me that doing gcc -print-multiarch (https://github.com/gkdr/libomemo/blob/master/Makefile#L9) might be the issue because it's a crosscompilation (host amd64 target aarch64) and gcc -print-multiarch as far as I understood it might print the wrong architecture (haven't dived in too deeply yet).

If we were to switch to meson f.e. that could solve such problems automatically :)
The same also applies to axc as well probably.

If you feel this should be a different issue (because this one has an emphasis on the storage/sqlite question) I can file a new one!

[pabs3]

Please note that gcc -print-multiarch probably doesn't work correctly on operating systems that use multilib instead of multiarch. Switching to another build system would fix that too, usually they just install to non-multiarch paths, but offer options to override the install locations, and then the distro package build systems override them to the multilib or multiarch paths.

[gkdr]

hi @fortysixandtwo!
i'm not against switching build systems. the current not-so-optimal project structure is a direct result of not wanting to deal with make any further back when i wrote it. there is an issue like that for lurch already: gkdr/lurch#148 meson also came up there, as pidgin uses it. the issue creator made a good point about CMake though: libsignal-protocol-c uses CMake and I think it would make sense to consolidate the build system in use instead of adding another one. there could be still points for meson, if it's e.g. considerably easier to learn/configure, since i currently know neither of those.

according to git blame you were the one who added that line to the makefile. what was the thought behind adding it? (just curious)

[fortysixandtwo]

according to git blame you were the one who added that line to the makefile. what was the thought behind adding it? (just curious)

I added this at the time when I was packaging it for Debian and wanted the libraries to be installed to /usr/lib/x86_64-linux-gnu (in the case for amd64) I actually wasn't aware of the crossbuilding issue at the time

[tehnick]

I was packaging it for Debian and wanted the libraries to be installed to /usr/lib/x86_64-linux-gnu (in the case for amd64)

If anyone interested, see rationale:
https://wiki.debian.org/Multiarch/Tuples
https://wiki.debian.org/Multiarch
https://wiki.ubuntu.com/MultiarchSpec

[fortysixandtwo]

The crossbuild issue is fixed by #36

[eli-schwartz]

meson also came up there, as pidgin uses it. the issue creator made a good point about CMake though: libsignal-protocol-c uses CMake and I think it would make sense to consolidate the build system in use instead of adding another one. there could be still points for meson, if it's e.g. considerably easier to learn/configure, since i currently know neither of those.

FWIW, meson has support for building cmake-based subprojects, so while you might end up having two build systems installed, you may not actually be interacting with anything other than meson.

Also, meson has https://wrapdb.mesonbuild.com/ which collects meson ports for various projects (that often do not already use meson), which are then available for any project to use. It is probably not very hard to port that one. You'd then go back down to one build system. :)

I am obviously extremely biased, but I do think meson is much easier to learn/configure, and it is particularly nice that meson can do dependency lookups which seamlessly support both finding system dependencies and finding subprojects, and allows the person building the software to choose which one is preferred. Adding subproject fallbacks for a dependency doesn't even require modifying the build system :) just adding a small ini file to the subprojects/ directory.