Integrate plugin build systems

[nemequ]

Squash bundles a lot of libraries in-tree, and we currently pretty much duplicate the existing build system for each library (though it is generally a slimmed down version). Ideally, we would like to be able to re-use the libraries' build systems so that we don't duplicate effort. Hopefully this would lead to quality improvements both in Squash and the libraries.

Unfortunately, even for projects which already use CMake, we can't just flip a switch and have them work. Projects will often build just an executable, and if they do provide a library it is usually shared not static. Also, usually they will install stuff (headers, libraries, executable, documentation, etc.), which we don't want.

From Squash's perspective, as well as anyone else who wants to bundle the library, what we need is a way to build a static library, disable any installation, control whether or not to have CTest run unit tests. Finally, it would be great if we could simply reference a target and have it automatically set any necessary flags (CMake ≥ 2.8.11 can do this, you just need to set the proper INTERFACE_* target properties). The result is that anyone who wants to embed the library in their build system would just do something like:

set(BROTLI_BUNDLE_MODE ON)
add_subdirectory(brotli)

target_link_libraries(mycode brotli)

Not only would compilation and linking just work, but the child project's unit tests could be automatically run when the parent project's run, documentation could be built, etc.

If you would like to see an example of a system which works the way we want, you can take a look at BriefLZ's. I'm willing to create/modify build systems as needed, assuming we have the cooperation of the libraries. I don't want to fork anything, so if the libraries aren't interested we'll just stick with the current system (basically, a duplicate build system living in Squash) for that plugin.

Obviously not everyone is familiar with CMake so part of this is that I would help with maintenance as needed. I also think getting some sort of CI set up for projects would be important (Squash uses both Travis and AppVeyor). At least then the developer should see notifications when they accidentally break the build.

The first thing I need to do is engage upstream developers to make sure that anything we do is acceptable to them. Basically, this means answering several questions:

First, are you willing to provide a CMake-based build system in your tree? If so, are you okay with making it flexible enough to meet our needs as described above? If no to either of those, we'll just keep using our existing system, it's not the end of the world. Otherwise, I need some more information before I start working on the system.

There are a couple different ways to structure everything:

1. Place a single CMakeLists.txt file in the top level of your project, which contains all the logic for your entire project. If you're familiar with autotools, this is like a non-recursive build system.
2. Place a CMakeLists.txt in the top level directory, as well as in each subdirectory. The top-level file will basically include each subdirectory's file. If you're familiar with autotools, it's a bit like a traditional recursive build system.
3. Put the CMake build system in a subdirectory somewhere (such as contrib/cmake).

Options (1) and (2) basically treat CMake as a first-class citizen, whereas (3) makes it pretty clear that CMake is an option, but may not really be the recommended way to build your project. Option (1) vs. (2) is mostly just about style; (1) puts your entire build system in one place, whereas (2) keeps the logic closer to the code. I prefer (2), but it's up to you.

Note that it may be necessary to put supplementary modules in a single directory somewhere. I usually use a cmake subdirectory alongside the highest level CMakeLists.txt, wherever that is.

Would you want CMake to replace your current system, or would you prefer for the two to exist in parallel?

Also, there are some optional features which I need to know if you would like to support (assuming you don't already, obviously we wouldn't want to remove features):

• Do you want to install a library and the header files?
  • If so, do you want to generate and install a pkg-config file? pkg-config is the preferred way to convey information about how other people should link to your library for pretty much everyone except CMake.
• If you have unit tests, would you like to install them? https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests lists some reasons you may want to.
• Would you like to provide an autotools-style configure script as an optional wrapper for your build system (see configure-cmake for details)

Note that, as mentioned above, installation would need to be optional (for projects integrating your project into their own tree).

Finally, if custom CMake modules are necessary (see https://github.com/quixdb/squash/tree/master/cmake for some examples), would you prefer to copy the modules into your tree, or use a git submodule?

I'll send out a message to each library's maintainer, and keep this issue updated.

• brieflz — Modify CMake to make BriefLZ easier to embed in other projects jibsen/brieflz#2
• brotli — Provide a build build system for both system-wide installation and bundling google/brotli#374
• bsc
• bzip2
• crush — N/A
• csc
• density
• doboz
• fari
• fastlz
• gipfeli
• heatshrink
• libdeflate — CMake ebiggers/libdeflate#20
• lzfse
• lz4 — cmake: significant changes to accomodate a new "bundled" mode. lz4/lz4#260 — available in unstable dev lz4 branch, squash will switch when it makes it to stable
• lzf
• lzg
• lzham — already uses CMake
• lzjb
• lzma
• lzo — already uses CMake
• miniz — already uses CMake
• ms-compress
• ncompress
• quicklz
• snappy
• wflz
• yalz77
• zlib — already has a CMake option
• zlib-ng — already has a CMake option, support known to lag
• zling — already uses CMake
• zpaq
• zstd — already has a CMake option