cmake build system for shared library

[selmf]

Hi Zeniko,

this is my take on a cmake based build system for unarr. It builds and installs unarr as a shared library on Linux and is probably usable on mac and win as well. It's written with packageability for Linux in mind and will detect and make use of the systems zlib and bzip2 installations. I'd be glad if you could take a look at it and maybe adapt it. Tell me if you need any modifications ;)

Regards,

selmf

[zeniko]

Thanks for the suggestion!

Unfortunately, I don't know CMake well enough to decide whether this is the right way to do it, let alone make improvements on it. So for now, I prefer sticking to a plain Makefile same as e.g. MuPDF and MuJS also manage to. (SumatraPDF was supposed to use CMake eventually but that plan has changed.)

One observation: If you're building unarr as a library, you might want to omit main.c; that's simply a sample/test executable not intended to be used in production (we use it among others for fuzzing and for batch testing).

[selmf]

Whoops, main.c crawled back in when I switched to using variables for the source lists instead of seperate CMakeLists.txt's in the subdirectories.

My experience with plain makefiles is limited. A shared library best fit's my use case for unarr (decompression backend for viewing comics, just what you made it for, target app is http://www.yacreader.com) and I needed to take win and mac into account too, so CMake was a logical choice and less challenging than learning makefile lingo from scratch.

If you prefer to stick with the plain makefile, here are some suggestions:

• use -O3 optimization for release builds, unarr really profits from it
• think about using -pthread for threading support
• zlib and bzip2 are standard libraries on linux/unix - it's safe to assume they're available. You can just add -lz and -lbz2 to the compiler flags.
• add a shared library target (compile with -fPIC, link with -shared and create a "libunarr.so" file)
• add a make install target (libs to /usr/lib, headers to /usr/include, binaries to /usr/bin)

I'm not sure If I can help make the makefile less experimental beyond these suggestions, but I'd really prefer not to keep using my own seperate build system for unarr forever, so I might take a closer look at it.

Since I'm planning to ship this as a seperate library package on linux rather than statically linking it, it would be great to have a release number and maybe a release tarball for the current version/state of unarr. This way, I could properly version and ship my packages as "libunarr" rather than building an application specific supplimental package to avoid versioning conflicts with unarr releases later on.

[zeniko]

Thanks for the suggestions. I've been experimenting a bit with the Makefile, but things don't look as easy as I'd hoped - especially given that I don't have much experience with writing proper Linux Makefiles. The one change I've made so far is change -O2 to -O3 (in commit c4136ab9c9b07682d400158f5f933414df959e63). About your other suggestions:

• I assume that -pthread isn't a magic bullet but would require the library to be rewritten for parallel decompression. In that case, that's not something I intend to do, mainly since we don't need the additional speed for SumatraPDF nor are most formats optimized for this (7z's LZMA2 being the main exception). What might work is a new API call to prepare a "closure" for decompressing on a different thread which would however require all the compressed data to be copied in-memory (since stream access isn't thread-safe). Then it would be up to the caller to handle threading as desired. BTW: That'd be similar to the solution MuPDF has picked as they don't want to bother with different threading solutions for different OSes, either.
• In my Debian box, neither -lz nor -lbz2 work as is, as Debian doesn't seem to consider this to be safe (apparently you have to explicitly specify the desired library version). I've considered requiring an explicit ZLIB_LIB and ZLIB_H argument to make for indicating where zlib is found, but that also feels like a kludge. Maybe CMake is the better option after all.
• As for shared library and install target, I'd include these changes if you (or anybody) can provide them as a pull request or diff.

Once you're happy with the build (Makefile and maybe CMake after all), I'll call it version 1.0, will look whether svn2git allows to add a v1.0 tag and point you to github's auto-tarballs for download. Up to that point, you'd have to specify the build by its git commit id or git commit count (given that unarr is entirely linearized due to it being imported through an SVN proxy) and still use github's auto-tarballs for download such as this link for the current head.

[selmf]

Thanks for your detailed answer!

You're right about -pthread. For some reason I was under the impression I got a speedup when I included it, but it must have been something else since unarr doesn't make any use of it.

I don't think a expansion for thread support is necessary, unarr is pretty fast as it is already.

Edit: The way you're describing -lz and -lbz2 not working, I'm suspecting that you don't have the development packages of zlib and bzip2 installed. These contain the library headers and also a "non-versioned" symlink to the latest version of the library on your system. For zlib and bzip2, you'll need these packages:

• zlib1g-dev
• libbz2-dev

Writing makefiles isn't a pleasant experience at all and the system has it's shortcomings. Most projects that I know of opt for the use of an automated build system that takes care of makefile generation for them (MuPDF being an excemption). It doesn't have to be CMake, there are other choices (I think you've opted for gyp in SumatraPDF?), but CMake is one of the few that also covers builds on non-unix systems.

FYI, I'll be closing this pull request shortly, as I need to update my repository and the CMake build to include the new lzma-sdk and I don't want to spam you with pull-request updates ;) I'll probably open an issue for the build system so we can continue our discussion there.