Boost logo

Boost-Build :

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-06-19 09:15:12


klapshin wrote:

> > > symlink hello_release : hello/<variant>release ;
> > >
> > >creates main target "hello_release" from the user point of view, but
> > >Boost.Build does something different. I think we should fix this. Rene,
> > >symlink was implemented by you, what do you think.
> >
> > Sure fixing it would be nice ;-) Problem is which name of the target
>
> do we
>
> > use in this situation:
> >
> > symlink hello_release hello_debug : hello/<variant>release
> > hello/<variant>debug ;
> >
> > As what's internally generated are three targets:
> >
> > symlink-targets; symlink#?
> > file-target; hello_release
> > file-target; hello_debug
>
> Well, there are two use cases. Suppose you have many projects, every
> one of them creates some convinience symlinks. Now you either work on
> one particular project and want to compile just debug, or both debug
> and release of that project. In this case it is acceptable to have
> command line syntax 'bjam hello_debug'.

I was thinking about the same.

> However there is another use
> case -- you might want to build all projects in release mode. Doing
> 'bjam release' from root will build both debug and release, which is
> annoying for small size projects and might be just unacceptable for
> big ones.

I agree. But see below.

> What about stage rule? Will it have similiar problems?

I think no. Here's what I have in my project:

stage wi-top
: $(2)
: <variant>debug:<location>$(CL_DIR)/$(1)-debug
<variant>release:<location>$(CL_DIR)/$(1)-optimized
;

I hope the idea is clear. If you build "wi-top" in release mode, it places
products to one dir. If you build it in debug mode --- to another. It does
not cause building of both variants. I think the same can be done with
symlink.

symlink hello_symlink : hello :
<variant>debug:<location>hello_debug
<variant>release:<location>hello_release
;

Now, <location> has no effect on "symlink", but probably it shoud?

- Volodya

 


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