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
> > 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.
> > 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.
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