Re: Duplicate target error

From: TEMPLIE Cédric (cedric.templie_at_[hidden])
Date: 2004-12-23 10:29:33

Vladimir Prus wrote:
> On Thursday 23 December 2004 17:12, TEMPLIE Cédric wrote:
> 
>>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.link.dll-project1.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.
> 
> 
> So, let me make sure I understand. A developer who's hacking on project3 might 
> not have any access to project1 or project2. However, he has access to the 
> stage dir, right?
> 
> In that case, I think the easiest solution would be to have the following:
> 
> lib project2 : : <search>$(STAGE_DIR) ;
> lib project3 : a.cpp project2 ;
> 
> So that Jamfiles of project2 are not even read (if developer don't have access 
> to project2, this seems reasonable).
> 
> What you're trying to do has some problems: you're trying to make project3 use 
> Jamfile of project2, but if sources of project2 are not accessible to a 
> developer, this won't work. Specifically, when building project2, bjam will 
> try to scan header dependencies in source files, and if they are not 
> readable, it will exit with an error.
> 
> - Volodya

In my root Jamfile, I done the following thing :

if [ glob Project1 ]
{
#Project1 sources available
use-project /project1 : ./project1 ;
}
else
{
#Project1 sources unavailable,
#so use already build libraries
use-project /project1 : $(STAGE_DIR) ;
}

In $(STAGE_DIR), there is a jamfile that declare same targets than in 
project1, but just point to needed file instead of building them...

Isn't it a valid solution ?

Thx

TEMPLIE Cédric

> 
> 
> 
> 
> Yahoo! Groups Links
> 
> 
> 
> 
> 
> 
> 
>