Re: [jamboost] Re: <library> (Was: I'm back!)

From: Vladimir Prus (ghost_at_[hidden])
Date: 2002-10-17 02:34:54

Markus Schöpflin wrote:

> > For your specific use case, we can have <runtime-link> affect
> > linking of system libraries, while <shared> will affect user
> > libraries.
> >
> > lib my : a.cpp ;
> > exe hello : hello.cpp my : <find-library>pcre ;
> >
> > Given this Jamfile, you can call
> >
> > bjam shared=false runtime-link=dynamic
> >
> > And "pcre" will be dynamically linked, while "my" will be static
> > library.
> 
> Don't you think that this will confuse most users? And isn't that 
> supported already for jam built libraries with <lib>my or <dll>my?

I don't find it confusing yet. Most linux application have 
"--enable-shared" or "--disable-shared" switch to configure, which 
controls how libraries internal to application are build -- either as 
static or as shared. I think it's quite reasonable: most libraries can
be build and used in either way, so it's just another features.

Regarding <lib>my / <dll>my. In V2 we don't use those prefixes that 
identify type, we just don't need them. And further, as I say above,
most of the time I don't want the request specifically static or shared 
library.

> > For a more general case, we might try <find-library-static> and
> > <find-library-shared>.
> 
> I think we absolutely need this. In the use case I mentioned above the 
> system libs are libm and libc and the libs I have to link to 
> statically are libs like openssl or libz which aren't build by 
> boost.build either.

Okay, noted.

> > Note that for use libraries, you can have this already:
> >
> > exe hello : hello.cpp my/<shared>false ;
> >
> > Will cause static linked version of "my" to be used, whatever build
> > request is.
> 
> Good to know.
> 
> There is another use case I have: Linking to oracle libs. On most 
> platforms, you _have_ to specify very exactly what get's linked and 
> how. Currenty I'm using the fact that a rule name can appear as the 
> prerequisite of a target. For example:
> 
> exe hello : hello.cpp : link_to_oracle_libs ;
> 
> and link_to_oracle_libs is a rule which inserts the right things in 
> the linker command line depending on the current build settings and 
> platform. It would be great if something like this would be supported 
> in v2 as well.

I think a minimal form of this is already supported. You can declare new 
target type ORACLE_EXE, and specify that it should be building in the 
same way as EXE, but with certain additional properties. Those 
properties can be computed dynamically.

- Volodya