Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-10-24 16:01:23

On Wednesday 24 October 2007 18:35:56 Jurko Gospodnetić wrote:
> Hi.
> Registering a second unrelated type for the same extension should be
> but is currently not acceptable. That should cause an error only if
> boost build does not, for some reason, know which type to choose but
> that is not always the case (see below for an example).
> Without this completely separate jam modules may cause conflicts when
> used in the same project if they use source files of different types
> with the same extension.
> We have several .jam modules modeling toolsets for different external
> tools we automate using and some of them run into this
> problem. E.g. internal LIB type is registered for the .lib extension but
> one of the tools uses the same extension for its own libraries. These
> libraries are built from their own sources and have nothing in common
> with C/C++ libraries or their sources and so should cause no confusion.
> We currently quick-fix for this by making sure only one type is
> registered for a single extension and making all other types derived
> from this one but this is not a good long term solution as it forces one
> toolset to know about others used in the same project.
> Should I add a TRAC item for this? Any chance someone more
> knowledgable could take a look at this?

Just to clarify -- there's are two mapping here. One is suffix -> type,
used when we need to decide what's the type of the source file, and
another is type->suffix, used to decide what's the suffix to use
on generated targets. The first mapping, naturally, does not allow
duplicate suffixes, but the second one does.

It's possible to first declare a type with no suffixes, and then
use type.set-generated-target-suffix to specify generated suffix

Will it help in your case?

- Volodya

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at