Final target paths proposal

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-10-23 09:59:10

Recent post by Hugo Duncan made me wonder if we need main target name in 
target path at all. I now believe that it's not needed. Consider a Jamfile 
with a single target

exe a : a.cpp ;

it's generated to "bin/gcc/debug/a". We change the Jamfile to read

exe a : a.cpp : <include>. ;

and Boost.Build sees extra property and generateds the target to "bin/gcc/
debug/main-target-a/a". Is there any problem with generating it to "bin/gcc/
debug". In this case, apparently, no. 

Problems only arise when two targets are generated with the same name, but 
different properties:

exe a : a.cpp : <define>A ;
exe b : b.cpp : <define>B ;

Here, putting "a.o" into bin/gcc/debug would create a conflict between two 
versions. 

However, I think it's acceptable to ask the user for help in this case. V2 
already has a code to detect situation when two different targets are 
assigned the same filename. We can decide that main target name is not 
encoded in path. In the case above, user will get an error telling that two 
target conflict. The user then can manually resolve conflict by writing

exe a : a.cpp : <define>A <location-prefix>a ;
exe b : b.cpp : <define>B ;

And targets will be generated to "bin/a/gcc/debug/a.o" and "bin/gcc/debug/
a.o".

IOW, I propose that the logic for automatically adding main target name to 
path is removed. If conflict between targets arises, user can add whatever 
path element he likes.

How does that sound? This solution will both simplify V2 code and target 
paths...

- Volodya