view release on metacpan or  search on metacpan

pod/makepp_build_cache.pod  view on Meta::CPAN

Rebuilding will remedy this, and the impact can be lessened by spreading the
files over several preferred disks.

Replication has several interesting uses:

=over

=item NFS (possible with copying too)

You have a central NFS server which provides the preferred build cache.  Each
machine and developer disk has a local build cache for fast submission.  You
either mount back all the developer disks to the NFS server, and perform the
replication and cleaning centrally, or you replicate locally on each NFS
client machine, treating only the part of the group visible there.

=item Unsafe disk (possible with copying too)

If you compile on a RAM disk (hopefully editing your sources in a
L<repository|makepp_repositories> on a safe disk), you can make the safe disks
be the preferred ones.  Then replication will migrate the files to the safe
disks, where they survive a reboot.  After every reboot you will have to
recreate the RAM disk build cache and add it to the group (which will give a
warning, harmless in this case, because the other group members still remember
it).

=item Full disk (hard linking to symbolic links only)

If one of your disks is notoriously full, you can make the build caches on all
the other disks be preferred.  That way replication will migrate the files
away from the full disk, randomly to any of the others.

=back



=head2 How to use a build cache

=head3 How to tell makepp to use the build cache

Once the build cache has been created, it is now available to makepp.  There
are several options you can specify during creation; see L<How to manage a
build cache> for details.

A build cache is specified with the
L<--build-cache|makepp_command/b_directory> command line option, with the
L<build_cache|makepp_statements/build_cache_path_to_build_cache> statement within a
makefile, or with the
L<:build_cache|makepp_rules/build_cache_path_to_build_cache> rule modifier.

The most useful ways that I have found so far to work with build caches
are:

=over 4

=item *

Set the build cache path in the environment variable MAKEPPFLAGS, like
this (first variant for Korn Shell or bash, second for csh):

    export MAKEPPFLAGS=--build-cache=/path/to/build/cache
    setenv MAKEPPFLAGS --build-cache=/path/to/build/cache

Now every build that you run will always use this build cache, and you
don't need to modify anything else.

=item *

Specify the build cache in your makefiles with a line like this:

    BUILD_CACHE := /path/to/build_cache
    build_cache $(BUILD_CACHE)

You have to put this in all makefiles that use a build cache (or in a common
include file that all the makefiles use).  Or put this into your
F<RootMakeppfile>:

    BUILD_CACHE := /path/to/build_cache
    global build_cache $(BUILD_CACHE)

On a multiuser machine you might set up one build cache per home disk to take
advantage of links.  You might find it more convenient to use a statement like
this:

    build_cache $(find_upwards our_build_cache)

which searches upwards from the current directory in the current file system
until it finds a directory called F<our_build_cache>.  This can be the same
statement for all users and still individually point to the cache on their disk.

Solaris 10 can do some fancy remounting of home directories.  Your home will
apparently be a mount point of its own, called F</home/$LOGNAME>, when in fact it
is on one of the F</export/home*> disks alongside those of other users.
Because it's not really a separate filesystem, links still work.  But you
can't search upwards.  Instead you can do:

    BUILD_CACHE := ${makeperl </export/home*/$(LOGNAME)/../makepp_bc>}

=back


=head3 Build caches and signatures

Makepp looks up files in the build cache according to their signatures.
If you are using the default signature method (file date + size), makepp
will only pull files out of the build cache if the file date of the
input files is identical.  Depending on how your build works, the file
dates may never be identical.  For example, if you check files out into
two different directory hierarchies, the file dates are likely to be the
time you checked the files out, not the time the files were checked in
(depending, of course, on your version control software).

What you probably want is to pull files out of the build cache if the
file I<contents> are identical, regardless of the date.  If this is the
case, you should be using some sort of a content-based signature.
Makepp does this by default for C and C++ compilations, but it uses file
dates for any other kinds of files (e.g., object files, or any other
files in the build process not specifically recognized as a C source or
include file).  If you want other kinds of files to work with the build
cache (i.e., if you want it to work with anything other than C/C++
compilation commands), then you could put a statement like this
somewhere near the top of your makefile: