Mpp::Signature -- Interface definition for various signature classes
Derive a package from this package.
Makepp is quite flexible in the algorithm it uses for deciding whether a target is out of date with respect to its dependencies. Most of this flexibility is due to various different implementations of the Mpp::Signature class.
Each rule can have a different signature class associated with it, if necessary. In the makefile, the signature class is specified by using the :signature modifier, like this:
%.o : %.c : signature special_build $(CC) $(CFLAGS) -c $(FIRST_DEPENDENCY) -o $(TARGET)
This causes the signature class
Mpp::Signature::special_build to be used for this particular rule.
Only one object from each different signature class is actually created; the object has no data, and its only purpose is to contain a blessed reference to the package that actually implements the functions. Each rule contains a reference to the Mpp::Signature object that is appropriate for it. The object is found by the name of the Mpp::Signature class. For example, the above rule uses the object referenced by
$Mpp::Signature::special_build::special_build. (The purpose of this naming scheme is to make it impossible to inherit accidentally a singleton object, which would cause the wrong Mpp::Signature class to be used.)
$signature = $sigobj->signature($objinfo);
This function returns a signature for the given object (usually a Mpp::File class, but possibly some other kind of object). A signature is simply an ASCII string that will change if the object is modified.
$sigobj is the dummy Mpp::Signature class object.
$objinfo is the a reference to makepp's internal description of that object and how it is to be built. See makepp_extending for details.
The default signature function simply calls $objinfo->signature, i.e., it uses the default signature function for objects of that class. For files, this is the file date concatenated with the file size.
A signature must not contain 22 consecutive characters that are alphanumeric or '+' or '/', unless the signature is dependent only on file content and expected to be alias-free. Otherwise, aliases can cause corruption when you use build caches. There probably ought to be a more robust way to determine whether a signature was generated by a method that is prone to aliasing.