You may need to patch sources to apply CMake best practices or hunterize package with dependencies.
In practice patching requires to have a fork of a project. In general it does not matter where the fork is located. But it matters that there is a central place for the patched packages:
If you want to create new fork let me know about it in a corresponding issue with “new package” label, I will create a new team and add you so you can push changes.
Please follow next rules:
- Instead of pushing changes directly to branch, open pull request so other developers can review your changes.
- Rebase your changes, check that history has not merge commits. In this case it will be easier to do review and reuse your work in future.
- Start working on patches from latest stable upstream tag. I.e. if latest
v1.3.15then create branch
hunter-1.3.15and add patches there. If you want to have version that is not released yet, say
da39a3e, then create branch
hunter-1.3.15-da39a3e. If there are not tags in upstream then start with dummy
v0.0.0version to avoid conflict with future releases, i.e. create branch
- Keep other branches in a clean state so we can always do
git merge --ff-onlyfrom upstream.
- Please do push commits only related to hunterization. Do not push general fixes and improvements, do push them upstream instead. Perfect hunterization should contain only:
- Test your changes. Add temporary release to Hunter system and
hunter_add_package(foo)is actually working. Do it at least for one toolchain locally but of course it will be better if you test all of them remotely.
Note that I’m not willing and can’t maintain all packages in practice. Therefore I do add all developers to the team if they ask to. If you want to be a maintainer, keep eye on changes, pull requests, be responsible for review and releases - let me know.
Also note that Hunter is designed to have zero maintenance for such tasks,
since you can add
HUNTER_ENABLED=OFF option at the top of the project
to skip all package management stuff (see Backward compatibility). It
means you can push branch
hunter to upstream without affecting
functionality of the project. As a summary it may sounds strange, but the final
goal of this organization is to have no forks of packages at all.