In our company, we're making the move to b2 as our build system.
As such, I'm trying to simplify our internal release procedure.

Background:
We have written a new rule "program" that wraps the exe rule and adds
a package.install target called "install" so that installing a
specific application is as easy as calling "b2 install --prefix=<path>".

Of course, when doing a full release we simply want to call "install"
at the top of the project tree.
I tried the following in the jamroot:

local rule explicit-alias ( id : targets + )
{
  alias $(id) : $(targets) ;
  explicit $(id) ;
}

for local l in $(all-progs)
{
  local project = [ MATCH (.*)/.* : $(l) ] ;
  local prog = [ MATCH .*/(.*) : $(l) ] ;
  explicit-alias $(prog) : apps/$(project)/$(prog)//$(prog) ;
  explicit-alias install-$(prog) : apps/$(project)/$(prog)//install ;
}

local rule install-progs ( id ) {
  for local l in $(all-progs) {
    local prog = [ MATCH .*/(.*) : $(l) ] ;
    install-$(prog) ;
  }
}

install-progs install ;
explicit install ;

(end of code)

This however creates the following error :
rule install-action_fill_pool unknown in module Jamfile</home/bisnode/workspace>

When I call the targets manually (e.g. $b2 install-action_fill_pool)
things work.
How can I make the targets created through the aliases available in the
jamfile itself?

I also tried working with a modified version of boostcpp.jam, but that
seems to remove the defauilt-build properties of the programs. Some
applications must be compiled with <threading>=multi, some not.
Sadly, I lack the knowledge in boost.build to understand how the
targets generated in boostcpp.jam can use the local aliases.
I think that understanding this might help in modifying it to allow
the retention of the application-specific properties.