Provide a build build system for both system-wide installation and bundling #117

New Issue

claunia · 2026-01-29T20:35:45Z

claunia commented

2026-01-29 20:35:45 +00:00

Originally created by @nemequ on GitHub (Jun 14, 2016).

Since Squash bundles Brotli in our tree, we basically maintain a separate build system for Brotli. I'm trying to reduce the amount of duplication between Squash and the libraries it bundles, so I'd like to be able to reuse Brotli's build system, which would mean making it compatible with our own (CMake-based) build-system. Obviously such a system wouldn't be specific to Squash; any project which uses CMake and wants to bundle Brotli could benefit from it. With such a system, bundling Brotli would be as simple as something like:

set(BROTLI_BUNDLE_MODE ON)
add_subdirectory(brotli)

target_link_libraries(mycode brotli)

Brotli would then be built as part of the parent project, including unit tests (which could also automatically integrate with ctest, so running make test would run brotli's tests as well) and documentation (if applicable).

The rest of this is largely copied from quixdb/squash#202, edited slightly to be specific to brotli.

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 (or two, if you want to separate the encoder and decoder), disable any installation, and 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).

If you would like to see an example of a system which works the way we want, take a look at BriefLZ's. I'm willing to create a similar system for Brotli, though obviously it would need to be a bit more extensive since Brotli is a larger project. I don't want to fork anything, so if you aren't interested we'll just stick with the current system for that plugin. Obviously not everyone is familiar with CMake so part of this is that I would help with maintenance as needed. However, before I proceed I need a few questions answered:

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, you can go ahead and close this issue and we'll keep interacting with Brotli just as we do today. Otherwise, there are a few ways to put this together:

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.
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.
Put the CMake build system in a subdirectory somewhere (such as contrib/cmake).

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.

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.

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 can't really 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? It's not very common, but 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 (projects integrating your project into their own tree probably don't want to install your CLI).

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?

Originally created by @nemequ on GitHub (Jun 14, 2016). Since [Squash](https://quixdb.github.io/squash/) bundles Brotli in our tree, we basically maintain a separate build system for Brotli. I'm trying to reduce the amount of duplication between Squash and the libraries it bundles, so I'd like to be able to reuse Brotli's build system, which would mean making it compatible with our own (CMake-based) build-system. Obviously such a system wouldn't be specific to Squash; any project which uses CMake and wants to bundle Brotli could benefit from it. With such a system, bundling Brotli would be as simple as something like: ``` cmake set(BROTLI_BUNDLE_MODE ON) add_subdirectory(brotli) target_link_libraries(mycode brotli) ``` Brotli would then be built as part of the parent project, including unit tests (which could also automatically integrate with ctest, so running `make test` would run brotli's tests as well) and documentation (if applicable). The rest of this is largely copied from quixdb/squash#202, edited slightly to be specific to brotli. 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 (or two, if you want to separate the encoder and decoder), disable any installation, and 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). If you would like to see an example of a system which works the way we want, take a look at [BriefLZ's](https://github.com/jibsen/brieflz/blob/master/CMakeLists.txt). I'm willing to create a similar system for Brotli, though obviously it would need to be a bit more extensive since Brotli is a larger project. I don't want to fork anything, so if you aren't interested we'll just stick with the current system for that plugin. Obviously not everyone is familiar with CMake so part of this is that I would help with maintenance as needed. However, before I proceed I need a few questions answered: 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, you can go ahead and close this issue and we'll keep interacting with Brotli just as we do today. Otherwise, there are a few ways to put this together: 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`). 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. 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. 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 can't really 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](https://en.wikipedia.org/wiki/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? It's not very common, but 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](https://github.com/nemequ/configure-cmake/) for details) Note that, as mentioned above, installation would need to be optional (projects integrating your project into their own tree probably don't want to install your CLI). 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?

claunia referenced this issue

2026-01-29 20:50:34 +00:00

[PR #117] Add "zopfli"-style backward reference search to brotli. #729

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/brotli#117