Add support for --recursive=separate pkg-bindist option mode

1 files changed, 51 insertions, 41 deletions

diff --git a/bpkg/pkg-bindist.cli b/bpkg/pkg-bindist.cli
index db372b8..7116e7d 100644
--- a/bpkg/pkg-bindist.cli
+++ b/bpkg/pkg-bindist.cli
@@ -79,18 +79,18 @@ namespace bpkg
      bpkg bindist -o /tmp/output/ libhello
      \
 
-     Unless the \cb{--recursive} option is specified, dependencies of the
-     specified package are translated to dependencies in the resulting binary
-     package using names and versions that refer to packages that would be
-     generated by the \cb{pkg-bindist} command (called \"non-native\"
-     packages). If instead you would like certain dependencies to refer to
-     binary packages provided by the distribution (called \"native\"
-     packages), then you need to arrange for them to be built as system (see
-     \l{bpkg-pkg-build(1)} for details). For example, if our \cb{libhello} has
-     a dependency on \cb{libsqlite3} and we would like the binary package for
-     \cb{libhello} to refer to \cb{libsqlite3} from Debian (or alike), then
-     the \cb{pkg-build} command would need to be (\cb{--sys-install} is
-     optional):
+     Unless the \cb{--recursive} option \cb{auto} or \cb{full} modes are
+     specified, dependencies of the specified package are translated to
+     dependencies in the resulting binary package using names and versions
+     that refer to packages that would be generated by the \cb{pkg-bindist}
+     command (called \"non-native\" packages). If instead you would like
+     certain dependencies to refer to binary packages provided by the
+     distribution (called \"native\" packages), then you need to arrange for
+     them to be built as system (see \l{bpkg-pkg-build(1)} for details). For
+     example, if our \cb{libhello} has a dependency on \cb{libsqlite3} and we
+     would like the binary package for \cb{libhello} to refer to
+     \cb{libsqlite3} from Debian (or alike), then the \cb{pkg-build} command
+     would need to be (\cb{--sys-install} is optional):
 
      \
      bpkg build --sys-install libhello ?sys:libsqlite3
@@ -245,18 +245,18 @@ namespace bpkg
      The resulting binary packages are placed into the standard \cb{rpmbuild}
      output directory (normally \c{\b{~/rpmbuild/RPMS/}\i{arch}\b{/}}).
 
-     Unless the \cb{--recursive} option is specified, dependencies of the
-     specified package are translated to dependencies in the resulting binary
-     package using names and versions that refer to packages that would be
-     generated by the \cb{pkg-bindist} command (called \"non-native\"
-     packages). If instead you would like certain dependencies to refer to
-     binary packages provided by the distribution (called \"native\"
-     packages), then you need to arrange for them to be built as system (see
-     \l{bpkg-pkg-build(1)} for details). For example, if our \cb{libhello} has
-     a dependency on \cb{libsqlite3} and we would like the binary package for
-     \cb{libhello} to refer to \cb{sqlite-libs} from Fedora (or alike), then
-     the \cb{pkg-build} command would need to be (\cb{--sys-install} is
-     optional):
+     Unless the \cb{--recursive} option \cb{auto} or \cb{full} modes are
+     specified, dependencies of the specified package are translated to
+     dependencies in the resulting binary package using names and versions
+     that refer to packages that would be generated by the \cb{pkg-bindist}
+     command (called \"non-native\" packages). If instead you would like
+     certain dependencies to refer to binary packages provided by the
+     distribution (called \"native\" packages), then you need to arrange for
+     them to be built as system (see \l{bpkg-pkg-build(1)} for details). For
+     example, if our \cb{libhello} has a dependency on \cb{libsqlite3} and we
+     would like the binary package for \cb{libhello} to refer to
+     \cb{sqlite-libs} from Fedora (or alike), then the \cb{pkg-build} command
+     would need to be (\cb{--sys-install} is optional):
 
      \
      bpkg build --sys-install libhello ?sys:libsqlite3
@@ -615,28 +615,31 @@ namespace bpkg
     string --recursive
     {
       "<mode>",
-      "Bundle dependencies of the specified packages. The <mode> value can be
-       either \cb{auto}, in which case only the required files from each
-       dependency package are bundled, or \cb{full}, in which case all the
-       files are bundled. Specifically, in the \cb{auto} mode any required
-       files, for example, shared libraries, are pulled implicitly by the
-       \cb{install} build system operation, for example, as part of
-       installing an executable from one of the specified packages. In
-       contrast, in the \cb{full} mode, each dependency package is
-       installed explicitly and completely, as if they were specified
-       as additional package on the command line. See also the \cb{--private}
-       option."
+      "Bundle or generate dependencies of the specified packages. The <mode>
+       value can be either \cb{auto}, in which case only the required files
+       from each dependency package are bundled, \cb{full}, in which case
+       all the files are bundled, or \cb{separate}, in which case a separate
+       binary package is generated for each non-system dependency.
+
+       Specifically, in the \cb{auto} mode any required files, such as shared
+       libraries, are pulled implicitly by the \cb{install} build system
+       operation, for example, as part of installing an executable from one of
+       the specified packages. In contrast, in the \cb{full} mode, each
+       dependency package is installed explicitly and completely, as if they
+       were specified as additional package on the command line. The
+       \cb{separate} mode is equivalent to invoking the \cb{pkg-bindist}
+       command on each dependency package. See also the \cb{--private} option."
     }
 
     bool --private
     {
       "Enable the private installation subdirectory functionality using the
-       package name as the private subdirectory. This is primarily useful
-       when bundling dependencies, such as shared libraries, of an executable
-       that is being installed into a shared location, such as \cb{/usr/}.
-       See the \cb{config.install.private} configuration variable
-       documentation in the build system manual for details. This option only
-       makes sense together with \cb{--recursive}."
+       package name as the private subdirectory. This is primarily useful when
+       bundling dependencies, such as shared libraries, of an executable that
+       is being installed into a shared location, such as \cb{/usr/}.  See the
+       \cb{config.install.private} configuration variable documentation in the
+       build system manual for details. This option only makes sense together
+       with the \cb{--recursive} option \cb{auto} and \cb{full} modes."
     }
 
     dir_path --output-root|-o
@@ -662,6 +665,13 @@ namespace bpkg
        troubleshooting."
     }
 
+    bool --allow-dependent-config
+    {
+      "Allow configuration that is imposed by dependent packages. Normally
+       this is undesirable because the resulting binary packages become
+       configured specificaly for particular dependent packages."
+    }
+
     string --os-release-id
     {
       "<v>",