NAME

Mpp::Signature -- Interface definition for various signature classes

USAGE

Derive a package from this package.

DESCRIPTION

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

   $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.

BUGS

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.