Re: [jamboost] Newbie bjam questions (v1)

From: Rene Rivera (grafik.list_at_[hidden])
Date: 2004-11-07 23:40:26

Andreas Huber wrote:

> Let me first say that bjam *rocks*. With an investment of just half a 
> day I got to a point where most of what I wanted to do works. 

:-)

>However, I 
> was unable to find answers to the following questions (see Jamfile 
> attached):
> 
> 1. Is there any way to "abstract away" <lib>/<dll>? For example, to 
> specify the Boost.Thread library as a dependency I had to add 
> <dll>../../thread/build/boost_thread to the sources. On Windows, the 
> static library variant doesn't exist so adding <lib>.. to the sources 
> leads to an error. This is ok, but I need to know/specify more than 
> absolutely necessary. It would be nice to just say that a target depends 
> on the thread library and the build system then figures out by itself 
> whether the static or the dynamic variant should be used (maybe through 
> a preference the user specifies on the command line).

There is in BBv2, but not really in BBv1. You can however do something like:

rule fsm-mt-example-build ( target-name : directory : sources + )
{
local fsm-boost-thread = <dll>../../thread/build/boost_thread ;
if $(OS) in NT
{
fsm-boost-thread = <lib>../../thread/build/boost_thread ;
}
exe $(target-name)
: $(directory)/$(sources).cpp
$(fsm-boost-thread)
<template>fsm-common-options
: <threading>multi
;
}

> 2. In boost::fsm all state classes contain virtual member functions but 
> have non-virtual destructors. GCC rightly issues a warning on this, 
> the gcc toolset and all its extensions (AFAICT, there are currently 5)? 
> Someday someone will add another extension and the warnings that are 
> disabled for the already existing extensions will appear for the new 
> extension until my Jamfile is adapted.

I'm not sure what your question is here?? O'wait by "extensions" you 
mean the difference gcc toolsets? If that's the case you can use the 
somewhat undocumented feature of property rules...

rule toolset::no-warn-non-virtual-dtor ( toolset variant : 
subvariant-path properties * )
{
switch $(toolset)
{
case gcc* :
return
$(subvariant-path) $(properties)
<cxxflags>-Wno-non-virtual-dtor ;

case * :
return
$(subvariant-path) $(properties) ;
}
}

And use it in the requirements section of your targets:

rule fsm-st-example-build ( target-name : directory : sources + )
{
exe $(target-name)
: $(directory)/$(sources).cpp <template>fsm-common-options
toolset:::no-warn-non-virtual-dtor
: <threading>single
;
}

> 3. In 1.31 the vc7.1 toolset seems to be broken wrt single-threaded 
> builds. When one tries to build with <threading>single the .cpp files 
> are not built with /ML (single-threaded) but with /MD (multi-threaded). 
> Is this a known issue?

Yes. It's fixed in the 1.32/CVS version.

> 4. I'm currently compiling PingPong.cpp twice with different target 
> names. This is due to the fact that the single-threaded exe target does 
> not depend on the threads dll while the multi-threaded target does. This 
> is somewhat inconvenient and I would rather like to say that 
> PingPong.exe is only dependent on the threads dll in multi-threaded 
> builds. Is there any way to do that?

Sounding like a broken record... Yes in BBv2, but not in BBv1 :-(

HTH

-- 
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq