Hello,
I am trying to use 2 toolsets and 2 version of each toolset in a boost build project. One particular toolset and version is to be used to create a file or executable which will be used later by all 4 toolset combinations (times variants).
I have run into a couple issues when trying to do this. The first is that when I try to build two versions of a file, one using the msvc 8.0 toolchain (I use a simple make rule as the example for TEST1 in attached project) and then the other simply using the
results of the output of the first (using the install rule), I get this:
bjam.exe msvc msvc-9.0 TEST1
...found 16 targets...
...updating 12 targets...
common.mkdir bin\install\msvc-8.0
common.mkdir bin\install\msvc-8.0\dbg
common.mkdir bin\gcc-mingw-4.5.2
common.mkdir bin\gcc-mingw-4.5.2\release
common.mkdir bin\gcc-mingw-4.5.2\release\threading-multi
Jamfile</c:/StarTeam/G2XXX_Displays/test>.in2out bin\gcc-mingw-4.5.2\release\threading-multi\file.h
common.copy bin\install\msvc-8.0\dbg\file.h
bin\gcc-mingw-4.5.2\release\threading-multi\file.h
1 file(s) copied.
common.mkdir bin\install\msvc-9.0
common.mkdir bin\install\msvc-9.0\dbg
common.mkdir bin\gcc-mingw-4.5.2\release\threading-multi\toolset-msvc:version-9.0
The directory name is invalid.
if not exist "bin\gcc-mingw-4.5.2\release\threading-multi\toolset-msvc:version-9.0\\" mkdir "bin\gcc-mingw-4.5.2\release\threading-multi\toolset-msvc:version-9.0"
...failed common.mkdir bin\gcc-mingw-4.5.2\release\threading-multi\toolset-msvc:version-9.0...
...skipped <pbin\gcc-mingw-4.5.2\release\threading-multi\toolset-msvc:version-9.0>file.h for lack of bin\gcc-mingw-4.5.2\release\threading-multi\toolset-msvc:version-9.0...
...skipped <pbin\install\msvc-9.0\dbg>file.h for lack of <pbin\gcc-mingw-4.5.2\release\threading-multi\toolset-msvc:version-9.0>file.h...
...failed updating 1 target...
...skipped 2 targets...
...updated 9 targets...
Notice the invalid directory it is trying to create. I would expect it to not need to do that since it should be installing file.h in the install dir for msvc 9.0 as it did for msvc 8.0?
The second issue arises when the target is an msvc exe which is used by another upstream target using gcc or msvc (using TEST in attached project):
bjam.exe gcc msvc TEST
c:/Tools/boost-build/share/boost-build/build\virtual-target.jam:1079: in virtual-target.register-actual-name from module virtual-target
error: Duplicate name of actual target: <pbin\msvc-8.0\debug\threading-multi>main.exe
error: previous virtual target { msvc%msvc.link-main.exe.EXE { msvc%msvc.compile.c-main.obj.OBJ { main.c.C } } }
error: created from ./main
error: another virtual target { msvc%msvc.link-main.exe.EXE { msvc%msvc.compile.c-main.obj.OBJ { main.c.C } } }
error: created from ./main
error: added properties: none
error: removed properties: <toolset-gcc:flavor>mingw <toolset-gcc:version>4.5.2
c:/Tools/boost-build/share/boost-build/build\virtual-target.jam:490: in actualize-no-scanner from module object(file-target)@122
c:/Tools/boost-build/share/boost-build/build\virtual-target.jam:135: in object(file-target)@122.actualize from module object(file-target)@122
c:/Tools/boost-build/share/boost-build\build-system.jam:749: in load from module build-system
c:\Tools\boost-build\share\boost-build\kernel\modules.jam:283: in import from module modules
c:\Tools\boost-build\share\boost-build\kernel\bootstrap.jam:142: in boost-build from module
c:\Tools\boost-build\share\boost-build\boost-build.jam:8: in module scope from module
I cannot figure out why this actual target is duplicated since it should only be trying to build the msvc version once? And should then install it to be used by the gcc version.
Of course I may be going about this the wrong way. I tried to do this without the install rule but then I would get upstream include paths with both GCC and MSVC specific location and a number of other headaches. Please enlighten me
if you have successfully accomplished something like this where an artifact is created with one toolchain/variant and then used by all other toolchain/variants (including the one that built the artifact) to do additional work.
BTW, I used gcc and msvc in this example. We actually use a different toolchain combination with the same results.
Thanks,
Chris