libminiz

Usage

Make sure to add the stable section of the cppget.org repository to your project's repositories.manifest to be able to fetch this package.

:
role: prerequisite
location: https://pkg.cppget.org/1/stable
# trust: ...

If the stable section of cppget.org is not an option then add this Git repository itself instead as a prerequisite.

:
role: prerequisite
location: https://github.com/build2-packaging/miniz.git

Add the respective dependency in your project's manifest file to make the package available for import.

depends: libminiz ^ 3.0.2

The library can be imported by the following declaration in a buildfile.

import miniz = libminiz%lib{miniz}

Configuration

There are no configuration options vailable.

Issues and Notes

• Currently, we do not use the same export header as generated by the builtin generate_export_header function that is provided by CMake. So, there could be differences in symbol visibility.
• The test fuzzers are only built and not executed, as they use something like oss-fuzz.
• The C++-based miniz_tester was considered. But as the original build system does not provide tests for this executable and compiling it fails on Windows- and MacOS-based configurations, it was removed.
• The amalgamation support was considered but deemed not to be necessary and removed. Tag v3.0.2 points to a version with a valid implementation and configuration variables. Please see Issue #1 for more information.

Contributing

Thanks in advance for your help and contribution to keep this package up-to-date. For now, please, file an issue on GitHub for everything that is not described below.

Recommend Updating Version

Please, file an issue on GitHub with the new recommended version.

Update Version by Pull Request

1. Fork the repository on GitHub and clone it to your local machine.
2. Run git submodule init and git submodule update to get the current upstream directory.
3. Inside the upstream directory, checkout the new library version X.Y.Z by calling git checkout vX.Y.Z that you want to be packaged.
4. If needed, change source files, buildfiles, and symbolic links accordingly to create a working build2 package. Make sure not to directly depend on the upstream directory inside the build system but use symbolic links instead.
5. Update library version in manifest file if it has changed or add package update by using +n for the n-th update.
6. Make an appropriate commit message by using imperative mood and a capital letter at the start and push the new commit to the master branch.
7. Run bdep ci and test for errors.
8. If everything works fine, make a pull request on GitHub and write down the bdep ci link to your CI tests.
9. After a successful pull request, we will run the appropriate commands to publish a new package version.

Update Version Directly if You Have Permissions

1. Inside the upstream directory, checkout the new library version X.Y.Z by calling git checkout vX.Y.Z that you want to be packaged.
2. If needed, change source files, buildfiles, and symbolic links accordingly to create a working build2 package. Make sure not to directly depend on the upstream directory inside the build system but use symbolic links instead.
3. Update library version in manifest file if it has changed or add package update by using +n for the n-th update.
4. Make an appropriate commit message by using imperative mood and a capital letter at the start and push the new commit to the master branch.
5. Run bdep ci and test for errors and warnings.
6. When successful, run bdep release --tag --push to push new tag version to repository.
7. Run bdep publish to publish the package to cppget.org.