view release on metacpan or  search on metacpan

t/data/generate/remctl/output/readme  view on Meta::CPAN

  with compiler flags defined by your Perl installation and installed into
  your local Perl module directory regardless of the --prefix argument to
  configure.  To change this, you will need to run perl Makefile.PL in the
  perl subdirectory of the build tree with appropriate options and rebuild
  the module after running make and before running make install.

  To also build the remctl PECL extension for PHP, pass the --enable-php
  option to configure.  The PHP PECL module build is handled by the normal
  PHP extension build system and therefore will be installed into your
  local PHP module directory.  The configure script will look for phpize
  on your PATH by default; if it's in some other directory, set the PHPIZE
  environment variable to the full path or set it on the configure command
  line.  The configure script for the PECL extension will be run during
  the build instead of during configure.  This is unfortunately apparently
  unavoidable given how the PECL build system works.

  To also build the Python bindings for the libremctl client library, pass
  the --enable-python option to configure.  The Python module build is
  handled by the normal Python extension build system, and therefore will
  be installed into your local Python module directory regardless of the
  --prefix argument to configure.  To change this, you will need to run
  python setup.py install by hand in the python directory with whatever
  options you want to use.

  To also build the Ruby bindings for the libremctl client library, pass
  the --enable-ruby option to configure.  The Ruby module build is handled
  by the normal Ruby module build system, and therefore will be installed
  into your local Ruby module directory regardless of the --prefix
  argument to configure.  To change this, override the sitedir variable on
  the make install command line, as in:

      make install sitedir=/opt/ruby

  The remctl build system also supports a few other environment variables
  that can be set to control aspects of the Perl, Python, and Ruby binding
  build systems.  These are primarily only of use when packaging the
  software.  For more information, a list of the variables, and their
  effects, see the comment at the start of Makefile.am.

  The Java client and server aren't integrated with the regular build
  system.  For information on building and installing them, see
  java/README.

  remctl will use pkg-config if it's available to find the build flags for
  libevent.  You can control which pkg-config binary and paths are used
  with the normal pkg-config environment variables of PKG_CONFIG,
  PKG_CONFIG_PATH, and PKG_CONFIG_LIBDIR, and you can override the
  pkg-config results with LIBEVENT_CFLAGS and LIBEVENT_LIBS.  Alternately,
  you can bypass pkg-config by passing one or more of --with-libevent,
  --with-libevent-include, and --with-libevent-lib to indicate the install
  prefix, include directory, or library directory.

  remctl will automatically build with PCRE support if pcre-config or the
  PCRE library are found.  You can pass --with-pcre to configure to
  specify the root directory where PCRE is installed, or set the include
  and library directories separately with --with-pcre-include and
  --with-pcre-lib.  You can also set PCRE_CONFIG to point to a different
  pcre-config script, or do similar things as with PATH_KRB5_CONFIG
  described below.

  remctl will automatically build with GPUT support if the GPUT header and
  library are found.  You can pass --with-gput to configure to specify the
  root directory where GPUT is installed, or set the include and library
  directories separately with --with-gput-include and --with-gput-lib.

  Normally, configure will use krb5-config to determine the flags to use
  to compile with your Kerberos libraries.  To specify a particular
  krb5-config script to use, either set the PATH_KRB5_CONFIG environment
  variable or pass it to configure like:

      ./configure PATH_KRB5_CONFIG=/path/to/krb5-config

  If krb5-config isn't found, configure will look for the standard
  Kerberos libraries in locations already searched by your compiler.  If
  the the krb5-config script first in your path is not the one
  corresponding to the Kerberos libraries you want to use, or if your
  Kerberos libraries and includes aren't in a location searched by default
  by your compiler, you need to specify a different Kerberos installation
  root via --with-krb5=PATH.  For example:

      ./configure --with-krb5=/usr/pubsw

  You can also individually set the paths to the include directory and the
  library directory with --with-krb5-include and --with-krb5-lib.  You may
  need to do this if Autoconf can't figure out whether to use lib, lib32,
  or lib64 on your platform.

  To not use krb5-config and force library probing even if there is a
  krb5-config script on your path, set PATH_KRB5_CONFIG to a nonexistent
  path:

      ./configure PATH_KRB5_CONFIG=/nonexistent

  krb5-config is not used and library probing is always done if either
  --with-krb5-include or --with-krb5-lib are given.

  GSS-API libraries are found the same way: with krb5-config by default if
  it is found, and a --with-gssapi=PATH flag to specify the installation
  root.  PATH_KRB5_CONFIG is similarly used to find krb5-config for the
  GSS-API libraries, and --with-gssapi-include and --with-gssapi-lib can
  be used to specify the exact paths, overriding any krb5-config results.

  Pass --enable-silent-rules to configure for a quieter build (similar to
  the Linux kernel).  Use make warnings instead of make to build with full
  compiler warnings (requires either GCC or Clang and may require a
  relatively current version of the compiler).

  You can pass the --enable-reduced-depends flag to configure to try to
  minimize the shared library dependencies encoded in the binaries.  This
  omits from the link line all the libraries included solely because other
  libraries depend on them and instead links the programs only against
  libraries whose APIs are called directly.  This will only work with
  shared libraries and will only work on platforms where shared libraries
  properly encode their own dependencies (this includes most modern
  platforms such as all Linux).  It is intended primarily for building
  packages for Linux distributions to avoid encoding unnecessary shared
  library dependencies that make shared library migrations more difficult.
  If none of the above made any sense to you, don't bother with this flag.

TESTING

  remctl comes with a comprehensive test suite, but it requires some
  configuration in order to test anything other than low-level utility