Re: [Boost-build] best was to handle external libs on windows and unix

Subject: Re: [Boost-build] best was to handle external libs on windows and unix
From: Jim Gallagher (jim_at_[hidden])
Date: 2009-04-02 18:16:10

>
> I think the simplest approach is to write a function that will do this:
>
> rule cots-lib ( name )
> {
>        return [ searched-lib $(name)
>             : # No sources
>             : <target-os>linux:<name> $(name)
>               <target-os>windows:<name>lib$(name)
>               <search>$(VEND_ROOT)/lib
>           ] ;
> }
>
> and then define libraries as:
>
>  cots-lib foo ;
>  cots-lib bar ;
>
> This is probably the best approach. An alternative approach is to
> - skip <name> from the metatarget declaration
> - add <tag>@myname
> - write myname tag rule that, for targets of SEARCHED_LIB type will
> adjust the name as desired. The "Builtin features" sections of the
> docs has documentation and C++ Boost Jamroot has an real usage example.
>
> Let me know if this helps.
>
> - Volodya
>

Volodya,

It turns out that some of the libs follow the convention, and some
don't. There are so many, I decided to write a Perl script to generate
this section of my Jamroot file. For the ones that don't follow the
convention, the script outputs two lines, like so:

lib libfoo : : <target-os>windows <search>$(VENDOR_ROOT)/lib ;
lib libfoo : : <target-os>hpux    <search>$(VENDOR_ROOT)/lib <name>foo ;

For the ones that do, it just outputs the expected:

lib bar : : <search>$(VENDOR_ROOT)/lib ;

This way, I don't have to analyze which libs follow the convention and
which ones don't, the script decides and outputs the entries, which I
copy into my Jamroot.

Thanks for your suggestion,
Jim