| | 29 | |
| | 30 | |
| | 31 | == Porting considerations == |
| | 32 | |
| | 33 | To automatically patch software with the BePorter tool, source tarballs should be diff'ed (cf. CreatePatch). |
| | 34 | |
| | 35 | Most projects however use SCM/VCS software including CVS, Subversion, git and Mercurial and accept patches only against their latest (HEAD) development version. A possible strategy is: |
| | 36 | |
| | 37 | 1. Download and try the latest released source tarball. If it works, no further steps are necessary. |
| | 38 | 1. Otherwise, check if the project maintains a publicly accessible (anonymous) source code repository. You might be able to choose between a branch corresponding to the version number of the source tarball or trunk. (Terminology varies between the VCS tools.) |
| | 39 | |
| | 40 | Doing so, you can easily track or revert your own changes, and this is the preferred format for submitting patches to the respective projects. |
| | 41 | |
| | 42 | Note that it is not easily automatable for BePorter though, but once accepted, future source tarballs promise to compile without patching. |
| | 43 | |
| | 44 | Also note that doing so may, depending on the project, result in more dependencies but might be easier to handle, for instance when modifying {{{configure.in}}} or {{{Makefile.am}}} instead of an Autoconf-generated {{{configure}}} or Automake-generated {{{Makefile}}}. |