dynamic artefact creation

[stefanseefeld]

provide support for artefacts to define more artefacts and inject them into the dependency graph as they are updated.

use-cases:

• source files need to be scanned to identify (additional) header-dependencies. This requires additional dependencies to be registered with the scheduler
• an artefact needs to be built but the list of its sources are only known after one of the prerequisite artefacts has been updated. This requires additional sources to be registered with the scheduler (which requires changes to the scheduler / bjam interface

[stefanseefeld]

As it turns out, it's relatively easy to do the following during the update operation:

• create new artefacts
• inject more dependencies into the graph
• add more sources to an artefact (as long as it hasn't been updated yet, or course)

What is not quite so easy is the definition of the data flow, so this requires more design.

use-cases:

• a config check results in the addition of a feature value (typically, a define, or some other compiler flag). How can that be promoted to all the places that need it ? How can features as well as feature-sets be shared, while also making sure that not all additions become global ?

In other words, we need to carefully reconsider how feature-value and feature-set objects can be defined to provide fine control over their scope and lifetime.