From: Vladimir Prus (ghost_at_[hidden])
Date: 2004-02-11 02:59:49
> > 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 ;
> Looking into my own problem the the matter seems rather more complicated
> :-( The problem revolves around the different way library sources are
> 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
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
Boost-Build list run by bdawes at acm.org, david.abrahams at rcn.com, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk