Built skel is called "skelbin". Each skelbin is placed in its own directory, containing nothing more than just that installed skelbin. In most cases that is done trivially by specifying --prefix=$SKELBINS/$NAME-$hsh in the skel. $NAME is the skel’s name, package’s name, something like perl-5.32.1.
$hsh is a supplementary hash value used to distinguish
different builds/revisions of the same package. Currently it is just a
hash of the skel itself and BASS’es current commit revision. It is
URL-safe Base64 encoded string. So for example if $SKELBINS is
/tmp/skelbins directory, then that Perl skelbin is installed to:
/tmp/skelbins/perl-5.32.1-zP3IpCa_XY7pGHCNYQxp_1KjQQNCyUl84LqSrWLErjA.
$NAME-$hsh is often called "namenhash" in the code.
But that is just a single software skelbin directory. What if my another
skel requires multiple other skelbins, depends on them?
GNU Stow helps there. That is
simple symbolic links manager. Assume you have got
/tmp/skelbins/perl5-$hsh0 and
/tmp/skelbins/gmake-4.4-$hsh1 skelbins and you current working
directory is /tmp/tmp.whatever. stow is used to create
symlinks from dependant skelbins to our current’s local/
subdirectory that way:
/tmp/tmp.whatever/local/bin/gmake -> /tmp/skelbins/gmake-4.4-$hsh1/bin/gmake /tmp/tmp.whatever/local/bin/perl5 -> /tmp/skelbins/perl5-$hsh0/bin/gmake /tmp/tmp.whatever/local/lib/site_perl -> /tmp/skelbins/perl5-$hsh0/lib/site_perl /tmp/tmp.whatever/local/share/info -> /tmp/skelbins/gmake-4.4-$hsh1/share/info [...]
If you add $tmp/local/bin to your $PATH and
$tmp/local/lib to $LD_LIBRARY_PATH, then both
gmake and perl will be available to that local build
and work perfectly. Alter $CFLAGS, $LDFLAGS,
$PKG_CONFIG_PATH and in most cases the whole building environment
will be aware about those skelbins.