mention how to generate patches
This commit is contained in:
parent
a0eadb76ea
commit
ceb5648eb7
@ -42,7 +42,8 @@ Naming
|
||||
understandable and be named according to what they're used for. File-local
|
||||
functions should be made static. We like lower case names.
|
||||
|
||||
See the INTERNALS document on how we name non-exported library-global symbols.
|
||||
See the INTERNALS document on how we name non-exported library-global
|
||||
symbols.
|
||||
|
||||
Indenting
|
||||
|
||||
@ -55,7 +56,7 @@ Indenting
|
||||
|
||||
Commenting
|
||||
|
||||
Comment your source code extensively using C comments (/* comment */), do not
|
||||
Comment your source code extensively using C comments (/* comment */), DO NOT
|
||||
use C++ comments (// this style). Commented code is quality code and enables
|
||||
future modifications much more. Uncommented code much more risk being
|
||||
completely replaced when someone wants to extend things, since other persons'
|
||||
@ -64,7 +65,7 @@ Commenting
|
||||
General Style
|
||||
|
||||
Keep your functions small. If they're small you avoid a lot of mistakes and
|
||||
you don't accidentally mix up variables.
|
||||
you don't accidentally mix up variables etc.
|
||||
|
||||
Non-clobbering All Over
|
||||
|
||||
@ -78,11 +79,11 @@ Non-clobbering All Over
|
||||
Platform Dependent Code
|
||||
|
||||
Use #ifdef HAVE_FEATURE to do conditional code. We avoid checking for
|
||||
particular operting systems or hardware in the #ifdef lines. The HAVE_FEATURE
|
||||
shall be generated by the configure script for unix-like systems and they are
|
||||
hard-coded in the config-[system].h files for the others.
|
||||
particular operating systems or hardware in the #ifdef lines. The
|
||||
HAVE_FEATURE shall be generated by the configure script for unix-like systems
|
||||
and they are hard-coded in the config-[system].h files for the others.
|
||||
|
||||
Separate Patches Doing Different Things
|
||||
Separate Patches
|
||||
|
||||
It is annoying when you get a huge patch from someone that is said to fix 511
|
||||
odd problems, but discussions and opinions don't agree with 510 of them - or
|
||||
@ -128,3 +129,21 @@ Test Cases
|
||||
in the test suite. Every feature that is added should get at least one valid
|
||||
test case that verifies that it works as documented. If every submitter also
|
||||
post a few test cases, it won't end up as a heavy burden on a single person!
|
||||
|
||||
How To Make a Patch
|
||||
|
||||
Keep a copy of the unmodified curl sources. Make your changes in a separate
|
||||
source tree. When you think you have something that you want to offer the
|
||||
curl community, use GNU diff to generate patches.
|
||||
|
||||
If you have modified a single file, try something like:
|
||||
|
||||
diff -u undmodified-file.c my-changed-one.c > my-fixes.diff
|
||||
|
||||
If you have modified several files, possibly in different directories, you
|
||||
can use diff recursively:
|
||||
|
||||
diff -ur curl-original-dir curl-modfied-sources-dir > my-fixes.diff
|
||||
|
||||
GNU diff exists for virtually all platforms, including all kinds of unixes
|
||||
and Windows.
|
||||
|
Loading…
Reference in New Issue
Block a user