Boost logo

Boost-Build :

From: TEMPLIE Cédric (cedric.templie_at_[hidden])
Date: 2004-12-23 09:12:42

Vladimir Prus wrote:

> On Wednesday 22 December 2004 16:13, TEMPLIE Cédric wrote:
> > I attach result file of tests I made...
> >
> > One with the bjam of M10, and the other one with the bjam you provide to
> > me.
> Ok, I finally see the problem (with msvc). However, I've lost track of
> what
> you're trying to do. Here's part of the error message:
> error: another virtual target {
> common%common.copy-project1.STAGED_SHARED_LIB
> { common%common.copy-project1.STAGED_SHARED_LIB
> {
> { msvc%msvc.compile.c++-project1.OBJ{ project1.CPP } } } } }
> V2 is trying to stage already staged target to the same location, and
> detects
> that it's something bad. There are two issues:
> 1. Why V2 is trying to do that
> 2. Why are you linking to staged lib
> The first question has a technical answer: your "lib project2 " links to
> result of staging "lib project1". There are two targets -- import lib and
> dynamic lib. The first is used during linking project2, but the second is
> not. So, building project2 returns three two Boost.Build targets -- dll
> project2, import lib project2 and dll project1. All of them are staged.
> I probably could do something about it, but here some the second question.
> The second question was already asked by Pedro -- why are you linking to
> staged library? I don't see any reason why you should. Could you clarify?
Yes, I will do my best to express what I want to do :)

To avoid to link with staged libraries, I wanted to use the <source>
utility... (like that I link with the project that is in <source>).
The project in <source> also stage its results in a common directory.
I use a common directory because I store the result on a particular
server (the common dir is a map drive on this server). Moreover,
swith the access rights of my developpers, they do not have access to
all the source code. Sometimes they need to works on
projects that uses some libraries that they cannot build (they do not
have the sources), so they use libraries from the common dir.
There is a special user that have access to all sources, and this user
can build all products from the top level.

But using <source> to attach dependency does not works... (the duplicate
target error appear).
So now I use <dependency> that allow me to build pre-requisite project.
Using dependency implies I need to link with staged libraries (I know
where they are).

But using <dependency> introduce a new duplicate target issue...
When in the same build I have to build the release and debug version of
the same library (that both use the same rule to export headers)
there is a duplicate target error due to headers staging....

The simple example attach show my problem...
It is a simple example, from the root, I want to build project2 and
project3, project2 needs project1 lib in release version,
and project3 need project1 lib with the building version.
Launch bjam from toplevel, and you will see the Duplicate target error.

This is what I wanted to use at the beginning (with <source>) but there
is also a duplicate target error....
I thing this way is cleaner than the first one, isn't it ?
Because in the first one (Test1) as the staged libraries are used, you
have to specify the name of libraries used in the linkflags...

I hope that it will help you to understand me....

Thx again


> - Volodya
> *Yahoo! Groups Sponsor*
> click here
> <*>
> ------------------------------------------------------------------------
> *Yahoo! Groups Links*
> * To visit your group on the web, go to:
> * To unsubscribe from this group, send an email to:
> jamboost-unsubscribe_at_[hidden]
> <mailto:jamboost-unsubscribe_at_[hidden]?subject=Unsubscribe>
> * Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service <>.
 --------------020409010305000502090507 Content-Type: application/x-zip-compressed;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------020409010305000502090507 Content-Type: application/x-zip-compressed;
Content-Transfer-Encoding: base64
Content-Disposition: inline;

[Attachment content not displayed.] --------------020409010305000502090507--

Boost-Build list run by bdawes at, david.abrahams at, gregod at, cpdaniel at, john at