Re: [jamboost] <file> specifier in library causes Duplicate name for actual target

From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-02-11 02:59:49

Hi Michael,

> > The <file> feature is going to be deprecated in M10 and removed some time
> > after that. You can use
> >
> >    alias lapack : : lapack.a ;
>
> Thanks for the reply. Certainly seems logical that the <file> should be
> deprecated in favour of the alias system. I assume your example should
> read. alias lapack : lapack.a ;

Yes, right.

> Looking into my own problem the the matter seems rather more complicated
> :-( The problem revolves around the different way library sources are
> interpreted.
>
> Previously I was using the follow complex definition:
> # System libraries - specify local link requirements for lapack
> lib g2c : : <name>g2c ;
> lib lapack : : <name>lapack ;
> lib lapack : : <toolset>gcc <name>lapack : : <library>g2c ;
> lib lapack : : <toolset>intellinux <name>lapack : : <library>g2c ;
> lib lapack : : <toolset>msvc <file>"../../CLAPACK3/clapack7.a" ;
> # The executable for testing
> exe rtheta : rtheta.cpp lapack ;
>
> This works fine (ignoring the <file> Duplicate name issue).
>
> In theory I would like to move the usage-requirement for g2c into the
> sources thus:
> lib g2c : : <name>g2c ;
> lib lapack : g2c : <toolset>gcc <name>lapack ;
>
> However this seems non functional when static linking. The library g2c is
> never propagated to an exe as a dependency. Similar the simpler
> lib lapack : g2c : <name>lapack ;
> does not propgate the g2c library dependency.

It should do it... maybe there's some bug, though.

> I am not sure if this a bug or I am missing something seriously important
> about how dependant libraries specified in sources list work when combined
> with a <named> library.
>
> On to the real problem. With regard to using alias definitions in this
> complex case. I can define my alias thus.
> alias clapack3_msvc : "../../CLAPACK3/clapack7.a" ;
>
> If I use this directly in the list of exe sources (instead of lapack)
> things are still good. However implementing the toolset dependant linking
> is not possible.
> lib lapack : clapack3_msvc : <toolset>msvc <link>static;
> fails in horribly with "clapack7.STATIC_LIB " as an unused source. This
> also happens if we place the named library directly into the list of
> sources thus: lib lapack : "../../CLAPACK3/clapack7.a" : <toolset>msvc
> <link>static;

That's a messy bug. When you write:

lib lapack : "../../CLAPACK3/clapack7.a" : <link>static;

Boost.Build tries to find a generator which can create STATIC_LIBRARY from a 
single source of type STATIC_LIBRARY. It fails to find any, since in fact no 
such generator exist.

Cool, so it thinks nothing is created and ignores source. Not nice :-(

But, OTOH, it looks that "lib" above is not what you're after. You're really 
creating alias, and can write

alias lapack : "../../CLAPACK3/clapack7.a" : <link>static;

It's not really good that "lib" behaves this way, but I'm not sure I'll fix it 
right now... 

- Volodya