Re: [jamboost] Re: Build variants

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-07-24 15:25:04

[2003-07-24] Paul Schmidt wrote:

>Ok, I'm back to dealing with the two processors, and it's getting
>closer. I've defined pairs of some variables based on the
><instruction-set> flag, but now there's a problem with accessing a
>library that gets built. I did this in the toolset:
>---
>flags snps2 SUFLIB <instruction-set>ee : .a ;
>flags snps2 SUFLIB <instruction-set>iop : .ilb ;
>---
>
>But now, a subproject jam file:
>---
>subproject iop/hello ;
>
>exe hello
> : hello.c <lib>../init/init
> : <instruction-set>iop <include>../include
>;
>---
>
>Can't find the library:
>
>....skipped <ee!hello\hello\snps2\debug\instruction-set-ee>hello for
>lack of <ee!init\init\snps2\debug\instruction-set-ee>init...
>
>
>Do I need to somehow mark the <lib> as belonging to a particular
>instruction set?

OK, it took me a while to figure out why you get the error. The problem is
that the SUF* (and PRE*) variables are used way before the influence of the
toolset. Basically it doesn't use the <instruction-set> feature in the
requirements to determine the name of the <lib> target in the sources.

And, I don't see any easy/immediate way to get what you are looking for. I'd
have to do some changes to Boost.Build to be able to do that.

Does your compiler require those extensions?

If not, I'd say use the standard .lib extension.

If yes, the easiest way I can think of handling it, without changing
Boost.Build itself. Is to fake Boost.Build and the tools into using the
extensions... Change your library link action to copy the result of the link
to the file with the .lib extension. That will fake out BB into thinking it
has the correct file. And also change the link to use your prefered
extension based on a var [like LIBSUF, not SUFLIB ;-)]

-- grafik - Don't Assume Anything
-- rrivera (at) acm.org - grafik (at) redshift-software.com
-- 102708583 (at) icq