path: root/doc/user/repositories.in

<!--

  Copyright (c) 2001, 2002, 2003 Steven Knight

  Permission is hereby granted, free of charge, to any person obtaining
  a copy of this software and associated documentation files (the
  "Software"), to deal in the Software without restriction, including
  without limitation the rights to use, copy, modify, merge, publish,
  distribute, sublicense, and/or sell copies of the Software, and to
  permit persons to whom the Software is furnished to do so, subject to
  the following conditions:

  The above copyright notice and this permission notice shall be included
  in all copies or substantial portions of the Software.

  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
  KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
  WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
  LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
  OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
  WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

-->

<!--


=head2 Repository dependency analysis

Due to its built-in scanning, Cons will search the specified repository
trees for included F<.h> files.  Unless the compiler also knows about the
repository trees, though, it will be unable to find F<.h> files that only
exist in a repository.  If, for example, the F<hello.c> file includes the
F<hello.h> file in its current directory:

  % cons -R /usr/all/repository hello
  gcc -c /usr/all/repository/hello.c -o hello.o
  /usr/all/repository/hello.c:1: hello.h: No such file or directory

Solving this problem forces some requirements onto the way construction
environments are defined and onto the way the C C<#include> preprocessor
directive is used to include files.

In order to inform the compiler about the repository trees, Cons will add
appropriate C<-I> flags to the compilation commands.  This means that the
C<CPPPATH> variable in the construction environment must explicitly specify
all subdirectories which are to be searched for included files, including the
current directory.  Consequently, we can fix the above example by changing
the environment creation in the F<Construct> file as follows:

  $env = new cons(
	CC	=> 'gcc',
	CPPPATH	=> '.',
	LIBS	=> 'libworld.a',
  );

Due to the definition of the C<CPPPATH> variable, this yields, when we
re-execute the command:

  % cons -R /usr/all/repository hello
  gcc -c -I. -I/usr/all/repository /usr/all/repository/hello.c -o hello.o
  gcc -o hello hello.o /usr/all/repository/libworld.a

The order of the C<-I> flags replicates, for the C preprocessor, the same
repository-directory search path that Cons uses for its own dependency
analysis.  If there are multiple repositories and multiple C<CPPPATH>
directories, Cons will append the repository directories to the beginning of
each C<CPPPATH> directory, rapidly multiplying the number of C<-I> flags.
As an extreme example, a F<Construct> file containing:

  Repository qw(
	/u1
	/u2
  );

  $env = new cons(
	CPPPATH	=> 'a:b:c',
  );

Would yield a compilation command of:

  cc -Ia -I/u1/a -I/u2/a -Ib -I/u1/b -I/u2/b -Ic -I/u1/c -I/u2/c -c hello.c -o hello.o

In order to shorten the command lines as much as possible, Cons will
remove C<-I> flags for any directories, locally or in the repositories,
which do not actually exist.  (Note that the C<-I> flags are not included
in the MD5 signature calculation for the target file, so the target will
not be recompiled if the compilation command changes due to a directory
coming into existence.)

Because Cons relies on the compiler's C<-I> flags to communicate the
order in which repository directories must be searched, Cons' handling
of repository directories is fundamentally incompatible with using
double-quotes on the C<#include> directives in any C source code that
you plan to modify:

  #include "file.h"	/* DON'T USE DOUBLE-QUOTES LIKE THIS */

This is because most C preprocessors, when faced with such a directive, will
always first search the directory containing the source file.  This
undermines the elaborate C<-I> options that Cons constructs to make the
preprocessor conform to its preferred search path.

Consequently, when using repository trees in Cons, B<always> use
angle-brackets for included files in any C source (.c or .h) files that
you plan to modify locally:

  #include <file.h>	/* USE ANGLE-BRACKETS INSTEAD */

Code that will not change can still safely use double quotes on #include
lines.


=head2 Repository_List

Cons provides a C<Repository_List> command to return a list of all
repository directories in their current search order.  This can be used for
debugging, or to do more complex Perl stuff:

  @list = Repository_List;
  print join(' ', @list), "\n";


=head2 Repository interaction with other Cons features

Cons' handling of repository trees interacts correctly with other Cons
features, which is to say, it generally does what you would expect.

Most notably, repository trees interact correctly, and rather powerfully,
with the 'Link' command.  A repository tree may contain one or more
subdirectories for version builds established via C<Link> to a source
subdirectory.  Cons will search for derived files in the appropriate build
subdirectories under the repository tree.

-->

  <para>

  Often, a software project will have
  one or more central repositories,
  directory trees that contain
  source code, or derived files, or both.
  You can eliminate additional unnecessary
  rebuilds of files by having &SCons;
  use files from one or more code repositories
  to build files in your local build tree.

  </para>

  <section>
  <title>The &Repository; Method</title>

 <!--

 The repository directories specified may contain source files, derived files
 (objects, libraries and executables), or both.  If there is no local file
 (source or derived) under the directory in which Cons is executed, then the
 first copy of a same-named file found under a repository directory will be
 used to build any local derived files.

 -->

    <para>

    It's often useful to allow multiple programmers working
    on a project to build software from
    source files and/or derived files that
    are stored in a centrally-accessible repository,
    a directory copy of the source code tree.
    (Note that this is not the sort of repository
    maintained by a source code management system
    like BitKeeper, CVS, or Subversion.
    For information about using &SCons;
    with these systems, see the section,
    "Fetching Files From Source Code Management Systems,"
    below.)
    You use the &Repository; method
    to tell &SCons; to search one or more
    central code repositories (in order)
    for any source files and derived files
    that are not present in the local build tree:

    </para>

    <scons_example name="ex1">
      <file name="SConstruct" printme="1">
       env = Environment()
       env.Program('hello.c')
       Repository('/usr/repository1', '/usr/repository2')
      </file>
      <file name="hello.c">
      int main() { printf("Hello, world!\n"); }
      </file>
    </scons_example>

    <para>

    Multiple calls to the &Repository; method
    will simply add repositories to the global list
    that &SCons; maintains,
    with the exception that &SCons; will automatically eliminate
    the current directory and any non-existent
    directories from the list.

    </para>

  </section>

  <section>
  <title>Finding source files in repositories</title>

    <para>

    The above example
    specifies that &SCons;
    will first search for files under
    the <filename>/usr/repository1</filename> tree
    and next under the <filename>/usr/repository2</filename> tree.
    &SCons; expects that any files it searches
    for will be found in the same position
    relative to the top-level directory XXX
    In the above example, if the &hello_c; file is not
    found in the local build tree,
    &SCons; will search first for
    a <filename>/usr/repository1/hello.c</filename> file
    and then for a <filename>/usr/repository1/hello.c</filename> file
    to use in its place.

    </para>

    <para>

    So given the &SConstruct; file above,
    if the &hello_c; file exists in the local
    build directory,
    &SCons; will rebuild the &hello; program
    as normal:

    </para>

    <scons_output example="ex1">
      <command>scons</command>
    </scons_output>

    <para>

    If, however, there is no local &hello_c; file,
    but one exists in <filename>/usr/repository1</filename>,
    &SCons; will recompile the &hello; program
    from the source file it finds in the repository:

    </para>

    <scons_example name="ex2">
      <file name="SConstruct">
       env = Environment()
       env.Program('hello.c')
       Repository('/usr/repository1', '/usr/repository2')
      </file>
      <file name="hello.c">
      int main() { printf("Hello, world!\n"); }
      </file>
    </scons_example>

    <scons_output example="ex2">
      <command>scons</command>
      gcc -c /usr/repository1/hello.c -o hello.o
      gcc -o hello hello.o
    </scons_output>

    <para>

    And similarly, if there is no local &hello_c; file
    and no <filename>/usr/repository1/hello.c</filename>,
    but one exists in <filename>/usr/repository2</filename>:

    </para>

    <scons_example name="ex3">
      <file name="SConstruct">
       env = Environment()
       env.Program('hello.c')
       Repository('/usr/repository1', '/usr/repository2')
      </file>
      <file name="hello.c">
      int main() { printf("Hello, world!\n"); }
      </file>
    </scons_example>

    <scons_output example="ex3">
      <command>scons</command>
    </scons_output>

    <para>

    </para>

  </section>

  <section>
  <title>Finding the &SConstruct; file in repositories</title>

    <para>

    &SCons; will also search in repositories
    for the &SConstruct; file and any specified &SConscript; files.
    This poses a problem, though:  how can &SCons; search a
    repository tree for an &SConstruct; file
    if the &SConstruct; file itself contains the information
    about the pathname of the repository?
    To solve this problem, &SCons; allows you
    to specify repository directories
    on the command line using the <literal>-Y</literal> option:

    </para>

    <literallayout>
      % <userinput>scons -Y /usr/repository1 -Y /usr/repository2</userinput>
    </literallayout>

    <para>

    When looking for source or derived files,
    &SCons; will first search the repositories
    specified on the command line,
    and then search the repositories
    specified in the &SConstruct; or &SConscript; files.

    </para>

  </section>

  <section>
  <title>Finding derived files in repositories</title>

    <para>

    If a repository contains not only source files,
    but also derived files (such as object files,
    libraries, or executables), &SCons; will perform
    its normal MD5 signature calculation to
    decide if a derived file in a repository is up-to-date,
    or the derived file must be rebuilt in the local build directory.
    For the &SCons; signature calculation to work correctly,
    a repository tree must contain the &sconsign; files
    that &SCons; uses to keep track of signature information.

    </para>

    <para>

    Usually, this would be done by a build integrator
    who would run &SCons; in the repository
    to create all of its derived files and &sconsign; files,
    or who would &SCons; in a separate build directory
    and copying the resulting tree to the desired repository:

    </para>

    <scons_example name="ex4">
      <file name="SConstruct">
       env = Environment()
       env.Program('hello.c')
       Repository('/usr/repository1', '/usr/repository2')
      </file>
      <file name="hello.c">
      int main() { printf("Hello, world!\n"); }
      </file>
    </scons_example>

    <literallayout>
      % <userinput>cd /usr/repository1</userinput>
      % <userinput>scons</userinput>
      gcc -c hello.c -o hello.o
      gcc -o hello hello.o
    </literallayout>

    <para>
    
    (Note that this is safe even if the &SConstruct; file
    lists <filename>/usr/repository1</filename> as a repository,
    because &SCons; will remove the current build directory
    from its repository list for that invocation.)

    </para>

    <para>

    Now, with the repository populated,
    we only need to create the one local source file
    we're interested in working with at the moment,
    and use the <literal>-Y</literal> option to
    tell &SCons; to fetch any other files it needs
    from the repository:

    </para>

    <literallayout>
      % <userinput>cd $HOME/build</userinput>
      % <userinput>edit hello.c</userinput>
      % <userinput>scons -Y /usr/repository1</userinput>
      gcc -c hello.c -o hello.o
      gcc -o hello hello.o
      XXXXXXX
    </literallayout>

    <para>

    Notice that &SCons; realizes that it does not need to
    rebuild a local XXX.o file,
    but instead uses the already-compiled XXX.o file
    from the repository.

    </para>

  </section>

  <section>
  <title>Guaranteeing local copies of files</title>

    <para>

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

    </para>

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

    <para>

    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 (not the local directory)
    contains the up-to-date &hello; program,
    and &SCons; correctly determines that nothing
    needs to be done to rebuild that
    up-to-date copy of the file.

    </para>

    <para>

    There are, however, many times when you want to ensure that a
    local copy of a file always exists.
    A packaging or testing script, for example,
    may assume that certain generated files exist locally.
    To tell &SCons; to make a copy of any up-to-date repository
    file in the local build directory,
    use the &Local; function:

    </para>

    <scons_example name="ex1">
      <file name="SConstruct" printme="1">
       env = Environment()
       hello = env.Program('hello.c')
       Local(hello)
      </file>
      <file name="hello.c">
      int main() { printf("Hello, world!\n"); }
      </file>
    </scons_example>

    <para>

    If we then 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:

    </para>

    <literallayout>
      % scons -Y /usr/all/repository hello
      Local copy of hello from /usr/all/repository/hello
      scons: `hello' is up-to-date.
      XXXXXX DO WE REALLY REPORT up-to-date, TOO?
    </literallayout>

    <para>

    (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.)
    XXXXXX DO WE REALLY REPORT up-to-date, TOO?

    </para>

  </section>