Re: [jamboost] Build variants

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-07-21 15:17:33

[2003-07-21] Paul Schmidt wrote:

>This is regarding building top-level binaries for either EE or IOP
>processors on the Playstation2.
>
>To clarify, I have a hierarchy:
>
>test
> iop
> foo
> ee
> init
> hello
>
>I want the "foo" project built using IOP-specific include and library
>paths, different link command files, and possibly completely different
>build tools from the "init" and "hello" EE-specific targets. And I
>want them built with a single invocation of bjam, e.g.
>
>bjam -s"TOOLS=snps2" -s"BUILD=debug <instruction-set>*"
>
>Demanding, aren't I? :-)

:-) -- OK, here are some answers...

Making each project use the IOP settings is easy, you just need to add
<instruction-set>iop to the requirements section of the targets that you
want built with it, and <instruction-set>ee for the others. That way you
don't specify it in the command line.

Now, using different tools is a bit harder...

If you mean that you want to use different toolsets, snps2-iop-tools.jam vs.
snps2-ee-tools.jam, then the only way I can think of doing something like
that is to use the "stage" target to limit what gets built based on the
toolset. There's an example of doing that in
boost-root/tools/build/examples/stage_source_selection.

But if you mean changing the command line executed, and still with the
single snps2 toolset, you'll need to use the <instruction-set> feature to
set some variables for the compiler tool to execute. Or you can execute
entirely different "actions" based on the instruction-set. Unfortunately I
don't see an example of the first one (the use of GXX in gcc-tools.jam is
the closest). The second is similar to what the borland-tools.jam does with
the extra link step it call (borland-IMPLIB-action).

>--- In jamboost_at_[hidden], Rene Rivera <grafik666_at_r...> wrote:
>> In the tools file you add something like what the gcc-tools.jam does:
>> 
>> flags snps HDRS <instruction-set>ee : $(SCE)\\EE\\INCLUDE ;
>> flags snps HDRS <instruction-set>iop : $(SCE)\\IOP\\INCLUDE ;
>> 
>> AND, you modify features.jam to add "ee" and "iop" as valid values
>for the
>> instruction-set feature.
>
>Ok, I've done that, and test-built my mini hierarchy for the ee. What
>it does, of course, is to add yet another level in the bin hierarchy,
>which I can live with if it's the only way to do it - but can I
>eliminate that extra level? Any given binary will be build either for
>the ee or the iop, never both, so there's no reason for the extra
>level of subdirectory. 

The extra level is needed, as there's no reasonable way to otherwise
differenciate the types of builds. But there are various ways to eliminate
all the extra subdirs. One is to use the "stage" target to put the resulting
executables in a more accessible location, I won't explain this as there are
easily understood examples for it already. The other is to define your own
variants. Defining your own variants tells the build system how to map a
single variant name to a set of features. So because it knows the set of
features it doesn't need to create the subdirs for what are usually added
features. If you look in the features.jam file you'll see at the bottom
things like: variant debug : common :... Those are defining the build
variants you use when doing "bjam -sBUILD=debug". You can define those in
your Jamrules files. Syntax is describe briefly in the docs, look for
"Variant Descriptions".

>In any case, I see how to set variables based on the instruction-set,
>but I'm still unclear as to how to trigger one or the other in a
>particular subinclude, e.g. if I write:
>
>subinclude <instruction-set>iop somedir ;
>
>somedir is still built even if my command line is:
>
>bjam -s"TOOLS=snps2" -s"BUILD=debug <instruction-set>ee" -d2 > out
>
>OTOH, if I can put an "<instruction-set>ee" somewhere in the subdir's
>jamfile:
>
>subproject ee/init ;
>lib init : init.c ;
>
>I can live with that, too.

Hmm, didn't understand that part. But I have a feeling I answered your
questions already.

>Suggestions? 

Usually ;-)

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