44 lines
1.7 KiB
Plaintext
44 lines
1.7 KiB
Plaintext
== 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/
|
|
- 0002-uninitializedcheck.patch: prevent uninitialized use of state->check
|
|
|
|
== 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
|