Re: boost-build support for pre-built boost libraries?

Daniel Wallin wrote:

> Roland Schwarz wrote:
>> Volodya,
>> 
>> I tried your suggested scriptlet, but there is a
problem with the
>> make-name rule which is invoked from the
<conditional>:
>> 
>> It does not have access to the name of the target.
If I follow your
>> suggestion blindly I would have to supply an unique
make-name for each
>> and every library. I guess this was not your
suggestion.
>> 
>> Then I tried to use the <tag> rule like so:
>> 
>> lib boost_program_options : : <name>real_name
<tag>tag ;
>> 
>> This looks better, because it does give me access
to all needed
>> information, but now I cannot change the name that
is handed to the -l
>> switch for the linker. Just "return
decorated_lib name ;" does nothing
>> :-(
>> 
>> Do you have any suggestions what I could try next?
> 
> I'm not completely up to speed with this discussion,
but how about
> deriving a new generator from `searched-lib`?

Or more specifically, introducing new type 'boost-lib' and
creating
a generator for it. That's ultimately best solution.

As Roland notes, what I've posted is raw sketch -- it's
possible
to make it support all boost libraries but it will require
lots of
copy-paste, and generator (that has access to requested
target name),
is in position to do this cleanly.

- Volodya


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

Vladimir Prus wrote:
> Daniel Wallin wrote:
>> I'm not completely up to speed with this
discussion, but how about
>> deriving a new generator from `searched-lib`?
> 
> Or more specifically, introducing new type 'boost-lib'
and creating
> a generator for it. That's ultimately best solution.

Hmm, maybe. Just another thought:

lib boost_program_options : : <name>make-name
;

Where <name> is allowed  to have a rule attached, and
is called with a 
similar set of parameters as <tag>mytags
rule. The difference would be, 
that the return value shall change real-name as opposed to
name (as tag 
does).

Btw.: Could someone please explain to me why the
"name" is not 
sufficient? Why does a SEARCHED_LIB need
"real-name"? I thought the name 
of a virtual-file-target already is supposed to be the name
in the file 
system, not?

Roland

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

Vladimir Prus wrote:
> Or more specifically, introducing new type 'boost-lib'
and creating
> a generator for it. That's ultimately best solution.

I am trying to go along this way... although my slope is
steep :-(

1) I am not able to derive from searched-lib-generator.
    I am not sure why. I tried to ...

       type.register BOOST_LIB : : SEARCHED_LIB ;

     because in builtin.jam within the linking-generator I
found the code
     that deals with searchable libs. So I believe, in order
to work with
     all supported toolsets I need to derive the BOOST_LIB
type from
     SEARCHED_LIB, else the code in linking-generator won't
work.

     However ...
     after having declared:

       boost-lib boost_thread : : <name>boost_thread
;

     this leads to the following output:

     /home/roland/local/boost-build/kernel/class.jam:93: in
new
     *** argument error
     * rule object(searched-lib-generator)58.__init__ (  )
     * called with: ( searched-lib-generator :  : BOOST_LIB
:  :  :  :  :
     :  )
     * extra argument searched-lib-generator

     I also tried to register a custom generator, but I have
no idea how
     I could do that, since I have to derive from
searched-lib-generator.

2) Is it possible at all to derive from
searched-lib-generator ?
    I suspect this will be possible:

    class searched-lib-generator : generator
    {
        rule __init__ ( )
        {
            generator.__init__ searched-lib-generator : :
SEARCHED_LIB ;
        }

    I cannot pass the BOOST_LIB type, because this generator
isn't
    supposed to accept any constructor parameters.
    The only way I could think of, is by-passing the
searched-lib
    __init__ !?
    E.g.:

    class boost-lib-generator : searched-lib-generator
    {
       rule __init__ ( )
       {
            generator.__init__ boost-lib-generator : :
BOOST_LIB ;
       }

    But I seriosuly doubt this is allowed.


Any further help / ideas highly appreciated !

Roland

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