Mentions légales du service

Skip to content
Snippets Groups Projects
user avatar
julia authored
git-svn-id: svn+ssh://scm.gforge.inria.fr/svnroot/abl/patchparse3@16600 49c04cc4-325e-4469-8343-7c70b988d817
b63d158c
History
Compilation:

make produces patchparse
make opt produces patchparse.opt, which should be faster

Execution:

Two suggested usage scenarios for focusing on semantic patches

--git directory start..end --min 20 --noall --noev --print-sp --notex

This uses the local git directory "directory" and considers all patches
from version "start" to version "end".  Each generated rule must apply at
least 20 times and in at least 3 files (the default value of the --minf
option).  There are some restrictions on what is printed (--noall and
--noev) and a semantic patch is generated but not a latex/pdf file.  The
semantic patch is generated in the "out" subdirectory which must already
exist.  The name of this directory can be controlled using the --out-dir
option.

--next directory --min 20 --notex

This does the same as the above, except that it takes the last two tags
beginning with next as the start and end; these are assumed to be the most
recent.


In both of the above cases (and whenever a semantic patch is generated) a
makefile is also generated in the out directory.  Each rule in the semantic
patch has a label in the makefile for getting the old and new versions of
all of the files in all of the patches from which the rule was derived.
The makefile is expected to be run from within the out directory.  Giving
make the extra argument DEST=path specifies a relative path from the out
directory where the files should be places.  The destination directory
should exist already.  The produced files have the original pathnames with
/ replaced by __, ie all files appear directly in the destination
directory.


A semantic patch is preceded by a list of the git codes that motivated its
construction.  This list includes the number of hunks that are not matched
by the given rule.  This number may be approximate, as it may refer to the
number of hunks not matched by any rule derived from the patch not the
given rule specifically (I don't know :).  Still this number can be used as
a hint as to how reliable the inferred patch is.

A semantic patch in which the + code uses some variables that are not
defined by the - code depends on the virtul rule invalid.  This makes it
possible to run the semantic patch as is.  If one finds other rules that
one does not like, one can add depends on invalid in their headers.
Likewise, if one can see how to fix an invalid rule, one can remove the
depends on invalid.


The --restrict argument restricts git to a particular directory, eg drivers.


It is also possible to generate a latex file which can be nicer for
browsing.  For this, drop the --notex option and add the option --giturl to
indicate the URL of the git repository.  The generated pdf file then
contains clickable links for seeing the patches.


Generated files have the name all_ followed by the versions concerned.


Calendar is a frontend for using patchparse.  It contains pathnames that
may need to be updated.


All of the software in this repository is covered by the GPLv2 license.