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.