| == Patches applied on top of zlib == |
| |
| - 0000-build.patch: changes from the upstream version, mostly related to the |
| build. |
| - 0001-simd.patch: integrate Intel SIMD optimizations from |
| https://github.com/jtkukunas/zlib/ |
| |
| == Procedure to create a patch file == |
| |
| Assuming you are working in a new feature branch: |
| - git format-patch master --stdout > foo.patch # where naming follows a growing |
| # number plus patch description. |
| - git add foo.patch |
| - git commit -a -m "Local patch." |
| - git rebase -i HEAD~2 # Squashing the second commit |
| |
| As patches created in this way will feature a ChangeLog, there is no longer |
| the need to append this file with a description of what the patch does. This |
| should help to solve frequent conflicts in pending new patches on |
| Chromium's zlib. |
| |
| The plan for the near future is to better insulate the platform specific |
| changes to ease update adoption with new releases of zlib. This insulation |
| happens by making changes inside contrib/ rather than the root directory |
| (where conflicts can happen). |
| |
| If a change modifies enough things inside the root directory that the |
| intention is not immediately clear, generate a .patch file to go with your |
| change. If the change's modifications in the root directory are small, like: |
| |
| #ifdef FEATURE_FLAG |
| use_special_feature(); |
| #elif |
| use_default_behavior(); |
| #endif |
| |
| then the intent is clear and a .patch file doesn't need to be generated (since |
| it would not provide much value). |
| |
| Ideally local changes should have a merge request featured in either: |
| - canonical zlib: https://github.com/madler/zlib/ |
| - zlib-ng: https://github.com/Dead2/zlib-ng |
