16.6. Guaranteeing local copies of files
Prev | Chapter 16. Building From Code Repositories | Next

## 16.6. Guaranteeing local copies of files

If the repository tree contains the complete results of a build, and you try to build from the repository without any files in our local tree, something moderately surprising happens:

    % mkdir $HOME/build2
    % cd $HOME/build2
    % scons -Q -Y /usr/all/repository hello
    scons: `hello' is up-to-date.

Why does SCons say that the `hello` program is up-to-date when there is no `hello` program in the local build directory? Because the repository contains the `hello` program, and SCons correctly determines that nothing needs to be done to rebuild that up-to-date copy of the file.

There are, however, times when you want to ensure that a local copy of a file always exists. For example, if you are packaging the result of the build, all the files used in the package need to be present locally, and the packaging tool is unlikely to know anything about SCons repositories. Similarly, if you build a unit test program, and then expect to run after the build, it doesn't help if the test program is somewhere else and wasn't rebuilt into the local directory. In these cases, you can tell SCons to make a copy of any up-to-date repository file in the local build directory, use the `Local` function:

    env = Environment()
    hello = env.Program('hello.c')
    Local(hello)

Now, if you run the same command, SCons will make a local copy of the program from the repository copy, and tell you that it is doing so:

    % scons -Y /usr/all/repository hello
    Local copy of hello from /usr/all/repository/hello
    scons: `hello' is up-to-date.

(Notice that, because the act of making the local copy is not considered a "build" of the `hello` file, SCons still reports that it is up-to-date.)

Prev | Up | Next
16.5. Finding derived files in repositories | Home | 16.7. Using Repository to separate source and build.