Registering a second unrelated type with the same extension.

   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 boost.build 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?

   Best regards,
     Jurko

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

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 boost.build 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
explicitly.

Will it help in your case?

- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build