Re: [Boost-build] Linking to decorated prebuilt libraries

From: Vladimir Prus (ghost_at_[hidden])
Date: 2007-08-15 14:27:17

On Monday 13 August 2007 15:03:14 Roland Schwarz wrote:
> 
> Vladimir Prus wrote:
> > Roland,
> > I thought about your patch and existing code. 
> > 
> > First note, already mentioned on IRC, is that I really don't like 
> > <name>+<real-name> -- this is fairly confusing.
> 
> Me too. (When I remember correctly I never suggested to use this.)
> 
> > I do think we should
> > be using <tag> -- for ordinary targets the name of target
> > is some 'base name' while <tag> is a hook to transform the name
> > according to properties. I think the same interface makes perfect sense
> > for a prebuilt library too.
> 
> I also think it this is much cleaner. What might look a little confusing 
> now is that presence of the <name> feature alone turns normal in 
> searched lib. (But this is not new.) <tag> alone (of course) is not 
> sufficient. (<search> also will do of course.) Hmm, but <name> now looks 
> a little bit redundant doesn't it?

Well, In theory the name of the target might be different from the
base name of the library. I'm not happy with magical behaviour of <name>,
but maybe it's not worth changing at this point.

> > 
> > Second, while reviewing your patch I noticed that searched-lib-target
> > is very crazy -- it has both 'name' and 'real-name' properties, where 'name'
> > is not used in any particular way. While fixing that, I've managed to make
> > <tag> work for searched lib target. The patch is attached.
> 
> Looks fine to me. (Altough I had no time yet to try it out.)

Okay, I'll commit it.

> > I also attach test Jamroot that *almost* works -- we only need to strip 'lib'
> > from the library names, as 'libboost_program_options-NNNN' is right name
> > for created library, but we need 'boost-program_options-NNNN' on
> > the linker command line.
> > 
> > What do you think?
> 
> As you might see from my suggested patches:
> 1) I modified the types, so SEARCHED_LIB will not generate the lib 
> prefix (which I think is wrong in the general case).

Ah, thanks to joys of GUI tools I have missed that part of your patch (lib.jam
change). Feel free to commit that change.

> 2) I modified the tag rule to take care for the lib prefix for windows only.

You mean this part:

        if $(type) = SEARCHED_LIB &&
            ( [ $(property-set).get <link> ] in static ) &&
            ( [ $(property-set).get <target-os> ] in windows ) 
        {
                name = lib$(name) ;
        }

I'm not sure I get the point, can you explain?

- Volodya