// file      : bpkg/pkg-build.cli
// copyright : Copyright (c) 2014-2017 Code Synthesis Ltd
// license   : MIT; see accompanying LICENSE file

include <bpkg/configuration.cli>;

"\section=1"
"\name=bpkg-pkg-build"
"\summary=build package"

namespace bpkg
{
  {
    "<options>
     <pkg-spec> <scheme> <pkg> <ver>
     <file>
     <dir>
     <rep-loc>",

    "\h|SYNOPSIS|

     \c{\b{bpkg pkg-build}|\b{build} [<options>] (<pkg-spec> | [\b{@}]<rep-loc> | <file> | <dir>/)...}

     \c{<pkg-spec> = [<scheme>\b{:}]<pkg>[\b{/}<ver>][\b{,}...\b{@}<rep-loc>]\n
        <scheme> \ \ = [\b{?}]\b{sys}}

     \h|DESCRIPTION|

     The \cb{pkg-build} command builds one or more packages including all their
     prerequisites. Besides building new packages, this command is also used to
     upgrade or downgrade packages that already exists in the configuration.

     Each package can be specified as just the name (<pkg>) with optional
     package version (<ver>) in which case the source code for the package
     will be automatically fetched from one of the configured
     repositories. See the \l{bpkg-rep-add(1)} and \l{bpkg-rep-fetch(1)}
     commands for more information on package repositories. If <ver> is not
     specified, then the latest available version will be built. To downgrade,
     the desired version must be specified explicitly. For example:

     \
     bpkg build foo libfoo/1.2.3
     \

     Alternatively, the package repository location (<rep-loc>) can be
     specified as part of the build command. In this case, if <ver> is not
     specified, then the latest available from this repository version will be
     built. For example:

     \
     bpkg build foo,libfoo/1.2.3@https://git.example.org/foo.git#master
     \

     If only the location is specified, then the latest versions of all the
     packages available directly from this repository will be built (note that
     this does not include packages available from complement repositories).
     The \cb{@} delimiter can be omitted if the location is a URL. For
     example:

     \
     bpkg build https://git.example.org/foo.git#master
     bpkg build @/path/to/repository/
     \

     A package name (<pkg>) can also be prefixed with a package scheme
     (<scheme>:). Currently the only recognized scheme is \cb{sys:} which
     instructs \cb{pkg-build} to configure the package as available from the
     system rather than building it from source. If the system package version
     (<ver>) is not specified, then it is considered to be unknown but
     satisfying any dependency constraint. Such a version is displayed as
     \cb{*}. In certain cases you may want to indicate that a certain package
     is available from the system but only add it to the configuration if it
     is required by other packages being built. In this case you can use the
     \cb{?sys:} system scheme variant.

     Finally, a package can be specified as either the path to the package
     archive (<file>) or to the package directory (<dir>\cb{/}; note that it
     must end with a directory separator). See the \l{bpkg-pkg-fetch(1)} and
     \l{bpkg-pkg-unpack(1)} commands for more information on the semantics of
     specifying the package as an archive or a directory.

     Packages that are specified explicitly on the command line will be
     \i{held}, that is, they will not be considered for automatic removal if
     they no longer have any dependents. Packages that are specified with the
     explicit package version (<ver>) or as an archive or directory, will, in
     addition, have their versions held, that is, they will not be
     automatically upgraded.

     The \cb{pkg-build} command also supports several options (described
     below) that allow you to control the amount of work that will be done."
  }

  class pkg_build_pkg_options
  {
    "\h|PKG-BUILD PACKAGE OPTIONS|

    The following options can be grouped to apply to a specific package as
    well as specified globally, in which case they apply to all the specified
    packages."

    bool --dependency
    {
      "Build, upgrade, or downgrade a package as a dependency rather than to
       hold."
    }

    bool --keep-out
    {
      "Keep output directories of external packages between upgrades and
       downgrades. Refer to \l{bpkg-pkg-disfigure(1)} for details."
    }
  };

  class pkg_build_options: configuration_options,
                           pkg_build_pkg_options
  {
    "\h|PKG-BUILD GLOBAL OPTIONS|"

    bool --yes|-y
    {
      "Assume the answer to all prompts is \cb{yes}."
    }

    string --for|-f
    {
      "<operation>",
      "Instead of the default \cb{update} build system operation, perform the
       \cb{update-for-}<operation> variant where <operation> is normally
       \cb{install} or \cb{test}."
    }

    bool --drop-prerequisite|-D
    {
      "Drop without confirmation prerequsite packages that were automatically
       built and will no longer be necessary."
    }

    bool --keep-prerequisite|-K
    {
      "Don't offer to drop prerequsite packages that were automatically built
       and will no longer be necessary."
    }

    bool --update-dependent|-U
    {
      "Update without confirmation dependent packages that are reconfigured
       due to their prerequisites being upgraded or downgraded."
    }

    bool --leave-dependent|-L
    {
      "Don't offer to update dependent packages that are reconfigured due to
       their prerequisites being upgraded or downgraded."
    }

    bool --configure-only|-c
    {
      "Configure all the packages but don't update."
    }

    bool --print-only|-p
    {
      "Print to \cb{STDOUT} what would be done without actually doing
       anything."
    }

    bool --no-fetch
    {
      "Don't fetch repositories specified as part of the build command."
    }

    bool --fetch-shallow
    {
      "Don't re-fetch complement and prerequisite repositories of repositories
       specified as part of the build command. Refer to the \cb{--shallow}
       option in \l{bpkg-rep-fetch(1)} for details."
    }
  };
}