|
Boost-Build : |
From: ep1s80 (jimsve_at_[hidden])
Date: 2005-04-19 01:59:42
--- In jamboost_at_[hidden], Vladimir Prus <ghost_at_c...> wrote:
> On Tuesday 19 April 2005 00:35, ep1s80 wrote:
>
> Hi,
>
> > I just recently discovered Boost build (v2). To learn how it
works I
> > have played with some small examples. In the Jamfile below my
intention
> > is to declare two libraries and one main executable. It seems bb
cannot
> > build this because both libraries depend on two different files
but
> > with identical names. If one of the open.cpp is renamed to
open2.cpp bb
> > builds both open.o and open2.o in the bin/gcc/debug sub
directory. Is
> > the really how it is supposed to be? Shouldn't the .o files be
placed
> > in seperate directories foo1 and foo2? Surely two different
libraries
> > in the same project must be able to depend on different but
identically
> > named source files. Maybe this can be solved with sub projects or
> > something, but, I really like to keep things as simple as
possible. Any
> > comments on this matter are welcom.
> >
> > # Jamfile
> > lib libfoo1 : foo1/open.cpp ;
> > lib libfoo2 : foo2/open.cpp ;
> > exe main : main.cpp ;
>
> The behaviour you see is by design. In this specific case we could
place the
> object file in two different directories. But there are some nasty
cases
> like:
>
> lib libfoo1 : ../../open.cpp ;
> lib libfoo2 : /tmp/open.cpp ;
>
> In those cases, it's absolutely unclear where targets must be
placed. So, for
> consistency, Boost.Build strips the directory name from source
files when
> determining target directories.
>
> You can find the previous discussion on this at:
>
> http://thread.gmane.org/gmane.comp.lib.boost.build/7606
>
> - Volodya
>
> --
> Vladimir Prus
> http://vladimir_prus.blogspot.com
> Boost.Build V2: http://boost.org/boost-build2
Thank you for the reply. I see your point. My opinion is however that
is would be better to append the relative directory paths and
disallow going down (".."). Anyway, I will continue to play with bb.
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