A4::Config - Configuration variables for A4
require A4:Config;
my $keep=$A4::Config::keep_host;
The A4::Config modules contains all of the site-specific configuration
variables for A4.
This module is typically configured at build-time, such that tests can be run on the specific configuration. See CONFIGURATION. Modifying the module in-situ should work, provided that you do it infrequently enough that the probability of somebody loading a bogus snapshot is negligible. However, modifications are not retroactive, so they might require nontrivial and widespread migration of legacy clients and data, unless you're careful to avoid that.
The values of variables defined in this module are derived when
perl Makefile.PL is run.
Strings in the master file A4/Config.pm.PL of the form
@@var@@ are replaced with constant Perl strings.
You can override the values of those strings by adding arguments of the form
var=value on the perl Makefile.PL command line.
If you do this, then ExtUtils::MakeMaker will generate corresponding
warnings, and you should ignore them.
If set to TRUE, then newly-created clients will retain the ``Host'' field by default. This is appropriate for platforms on which development takes place predominantly inside directories that are not visible or not writable from other hosts on the same network.
This setting can be overridden when a client is created. Furthermore, the ``Host'' field may be manually added or removed after the fact.
If set to TRUE, then newly-created clients will specify P4PORT in the .p4env file that is created in the client's root directory. This is appropriate for sites that have multiple perforce servers running simultaneously in the same domain. (That's usually a bad idea, but this option will make your life a lot easier if it's beyond your control.)
The down side to this option is that if you migrate the server to another host and/or port, you'll need to change every single existing client in addition to the user environments. Changing hosts can be facilitated with a host alias, provided that the old host is decommissioned or has its name changed. Changing ports can be facilitated (under UNIX) by using the NIS services map, provided that existing clients make use of it.
This setting can be overridden when a client is created. Furthermore, the .p4env file may be manually edited after the fact.
If defined and the P4PORT environment variable is not already set on invocation, then use its value. This is useful if there is only one Perforce server that services A4 clients, and that server's address is not the default (perforce:1666), or you are mapping the port number through NIS.
For example, if your perforce server host has an alias of ``p4host'' listening on port 1666, and your NIS maps ``p4service'' to ``1666/tcp'', and NIS is supported on the client platform, then setting this to ``p4host:p4service'' (rather than the canonical hostname and numerical port) will make your life easier if you ever need to migrate your server.
When used in conjunction with $keep_port, the typical user will never have to set his P4PORT environment variable, even in his startup files.
The name of the user that p4d(1) runs as.
Only this user will be able to run submit regressions as a user making a
submission.
It is recommended that this user account be visible across the network, such
that it can log into the client machine.
The name of a Perforce user who has Perforce super privilege on the entire
depot.
If this user has a Perforce password (and it probably should), then it is
assumed that this user's home directory contains a (presumedly unshared)
file called .p4passwd that contains the unadorned password by itself
on the first line.
It is recommended that this user account be visible across the network.
The name of the directory containing ``current'' executables associated with A4 on the host running the Perforce service. This is used for setting up submit triggers. Ideally, it should be some path that is automatically updated (e.g. through a symbolic link) to point to the ``current'' installed version of A4, such that it will still work when the present installation is removed. Defaults to the INSTALLSCRIPT Makefile variable.
The directory containing the executables associated with this install of A4. Defaults to the INSTALLSCRIPT Makefile variable, and you probably shouldn't override it. It is assumed that if you're able to load A4::Config, then there is some intact binary directory that is associated with the same install, and this variable points to it.
The path of the Perl executable, for interpolation into configured scripts. Defaults to $Config::Config{'perlpath'}.
NOTE: This variable normally has no effect because the shell path is
obliterated by the $(FIXIN) script.
If you want to actually see this in the installed scripts, then you need to
specify FIXIN=/bin/true on the make command line.
This should be configured via the a4perl installation variable.
The ``current'' library directory (containing A4::Config) to use for Perl scripts generated by A4. This is used to determine what to add to the @INC when running the client-side presubmit wrapper. As with $server_bindir, you can set this manually to more gracefully deal with obsolete installs of A4. By default, the library install directory is used.
A Perl expression to evaluate in array context to yield the directories containing Perl reference libraries. The architecture-dependent subdirectory is automatically added for each array entry. This is useful when you have ``legitimate'' modules from the CPAN modules list installed somewhere other than the Perl installation directory (for example, because you don't want to destabilize the main Perl libraries).
By default, this is ``()''.
To get lines to interpolate into a script use the return value of reflibs().
A Perl expression to evaluate in array context to yield the directories containing libraries associated with A4 scripts. Typically, this is only used when building A4 itself. By default, we invoke a path relative to the script itself, so that the install can be copied to another directory and modified.
To get lines to interpolate into a script use the return value of script_libdir().
Specifies the port for the A4 database server in the same format as $p4port.
If it's an integer less than 1000, then the port is determined by adding it
to the perforce port number (as returned by A4::get_port).
If it doesn't have a colon (:), then the host is derived from $p4port.
The a4port() routine returns the result as a 2-element array in
($host, $port) format.
It is recommended that the A4 database server run on the same host as the Perforce database server, so as to minimizes the number of failure points.
The version number of A4 as a whole. You shouldn't attempt to override this. It guaranteed to be accurate only if you're using an official unmodified release distribution of A4.
The path of the p4(1) executable. ``p4'' by default.
The name of the file that defines the Perforce configuration, which is assumed to be the value of every user's P4CONFIG environment variable. ``.p4env'' by default.
NOTE: In several places, the documentation will continue to refer to ``.p4env'' even if this variable is set to something else. This might get fixed in the future.
The location of the TRUNK codeline. ``//depot/top'' by default.
The name of the directory below the client root that contains the a4 codeline configuration information. ``CFG'' by default.
NOTE: In several places, the documentation will continue to refer to ``CFG'' even if this variable is set to something else. This might get fixed in the future.
The path of the patch(1) executable. ``patch'' by default.
NOTE: Many systems have an older version of patch(1) that may not work
properly with a4, for example, because it can't patch files with the
write permission disabled. If you use a4 on any such systems, it is
recommended that you set this to something like /usr/local/bin/patch,
and make sure that you have an updated version of patch(1) installed there.
Used by the default platform2dir() to map the platform name ($^O by default)
to the default refbuild prefix directory.
This should be configured as a string that evaluates to a hashref.
Maps a platform name to the refbuild prefix directory, or emit an exception if no such directory location can be found.
This should be configured as a string that evaluates to a coderef, for example:
# This is all on a single command line:
perl Makefile.PL platform2pdir='sub { my ($p)=@_;
my $d="/refbuilds/$p"; return $d if -d $d;
die "Reference builds not supported for platform $p";}'
The path of a Perl executable supporting SUID execution, for interpolation into configured SUID scripts. This is useful when the version of Perl that normally runs A4 isn't equipt to run SUID (for example, because it wasn't installed as root). You may include switches in suidperl.
A Perl expression to evaluate in array context to yield the directories containing Perl reference libraries to include for SUID scripts. Ignored unless $suidperl is set. This is useful because -I switches are not allowed in SUID mode.
By default, this is ``()''.
A4::Config variables might not wind up being what they should be in
order for A4 to operate properly.
FindBin, it's not actually loaded unless
$script_libdir is eval'ed.
See FindBin/KNOWN ISSUES for information about the dangers of loading
FindBin.
A4