Prebuild libs

From: Brian Ravnsgaard Riis (brian_at_[hidden])
Date: 2005-09-18 17:16:53

Hi list.

I've been working on a project for some time now, and have been
using BBv2 as build system. I use several pre-built libraries from
a central storage. I would really like to have these included
automatically in the correct version depending on toolset used and
build variant. These files naturally have different names,
depending on above, so I cooked up the following scheme. (The
appropriate directory has already been added in the Jamroot file).

lib somelib_gcc
:
: <variant>debug:<name>somelib-gcc-sd
<variant>release:<name>somelib-gcc-s
;

lib somelib_msvc
:
: <variant>debug:<name>somelib-msvc-sd
<variant>release:<name>somelib-msvc-s
;

alias somelib
: somelib_gcc
: <toolset>gcc
;

alias somelib
: somelib_msvc
: <toolset>msvc
;

exe someprogram
: $(SOURCES).cc
somelib
;

SOURCES is of course defined, and gcc above is intended to be
MinGW. I used a CVS HEAD as of June 2 this year, and the above
scheme, though a bit cumbersome, worked. It doesn't with current
CVS, however. I get an error message to the following effect:

*** argument error
* rule object(searched-lib-target)@1.__init__ ( name : project :
shared ? : real
-name ? : search * : action )
* called with: ( somelib_gcc : object(project-target)@8 : true : somelib-gcc
-sd somelib_gcc : /D:/Lib/Boost/lib /D:/Lib/wxWidgets/lib :
object(null-action
)@1 : : : )

As you can see the real-name parameter gets passed both the real
name *and* the lib name. The culprit is a fix to "# Support " lib a
; " and " lib a b c ; " syntaxes." in tools/builtin.jam. It
searches requirements for <name> but only if <name> comes first,
not as dependent argument as above.

When I encountered this, I tried rearranging a bit as per an
example from the tutorial.

lib somelib_gcc
:
: <name>somelib-gcc-sd <variant>debug
;
lib somelib_gcc
:
: <name>somelib-gcc-s <variant>release
;

lib somelib_msvc
:
: <name>somelib-msvc-sd <variant>debug
;

lib somelib_msvc
:
: <name>somelib-msvc-s <variant>release
;

alias somelib
: somelib_gcc
: <toolset>gcc
;

alias somelib
: somelib_msvc
: <toolset>msvc
;

exe someprogram
: $(SOURCES).cc
somelib
;

Now I get an error to this effect:
error: failed to build ../../src/util/somelib_gcc with properties
because no best-matching alternative could be found

I'm unsure why this doesn't work, aside from the distinct
possibility that I am trying to do something illegal with BBv2.
Anyway, I then cooked this up. It's getting severely cumbersome and
a regular maintenance nightmare, but...

lib somelib_gcc_debug
:
: <name>somelib-gcc-sd
;
lib somelib_gcc_release
:
: <name>somelib-gcc-s
;

lib somelib_msvc_debug
:
: <name>somelib-msvc-sd
;

lib somelib_msvc_release
:
: <name>somelib-msvc-s
;

alias somelib
:
: <toolset>gcc
<variant>debug:<library>somelib_gcc_debug
<variant>release:<library>somelib_gcc_release
;

alias somelib
:
: <toolset>msvc
<variant>debug:<library>somelib_msvc_debug
<variant>release:<library>somelib_msvc_release
;

exe someprogram
: $(SOURCES).cc
somelib
;

Now the syntax gets accepted, but the libraries are not added to
the link, resulting in a load of link-time errors.

Thoughts?

-- 
/Brian Riis