2. Please get someone to tell me the answer to the question that you want the guide to answer ;-)

I've found that you need --toolset=msvc msvc/architecture=x86/address-model=64 But I'm still having a great deal of trouble finding a command line that works reliably. I got everything built once but trying to build it again from inside my Visual Studio "solution" is going badly. Static/static works but most combinations of link and runtime-link involving at least one "shared" are failing with duplicate target errors. I'm trying to build --with-regex and --with-test; I've tried one command line and one per lib/link/runtime-link combination with no luck. I have found an intermediate set of notes but not my final notes from my previous go-round with bjam. Sigh. There are add-on tools, Compuware's Devpartner for instance, that when active want to rebuild all the code in a program that isn't part of a system library. Also, optimization choices like _SECURE_SCL, WPO/PGO, and omit_frame_pointer work better when you build custom support libraries to match the choices. This is a nightmare without automation. After quite a bit of messing around with it, writing the infrastructure to translate the settings from Visual Studio's build engine into bjam command line parameters, I'm leaning toward writing visual studio project files for the two precompiled libraries we depend on. It is a more maintenance-intensive solution in the long run but it might actually work. Bjam might too but that's apparently a matter of luck. Well, cargo-cult programming and luck. The "build" command of my "Makefile"-type project is (manually line-wrapped): for /F "tokens=1-3" %%i in (configs.txt) do ( echo building %%i %%j %%k bjam --toolset=msvc-9.0 --build-dir="$(OutDir)boost" --with-%%i msvc/architecture=$(PlatformArch)/address- model=$(PlatformBitness)/link=%%j/runtime-link=%%k define=_SECURE_SCL=$(SecureSCLValue) -d0 $(BoostConfiguration) stage ) The "rebuild" line is the same but add -a, the "clean" line is the same but add clean. Use the ... button at that shows up when you click in the command line text box to pop up a multiline script editing window. Join the bjam command text onto one line, no space before model. Use copy-and-paste with "All Configurations" and "All Platforms" selected to populate the rebuild and clean command lines, then edit each to add the modifiers. The boost.vcproj file is located in the root of the boost source tree and configs.txt, in the same directory, contains: regex static static regex shared shared regex static shared test shared shared The boost Makefile project inherits, in each Debug/Release cross-product Win32/x64 configuration, from a .vsprops (property sheet) file named for the configuration: e.g. Debug-Win32.vsprops. You set that up using the Property Manager window; there's apparently no way to do so using the regular property editing dialog for a Makefile project. In the property sheets define the PlatformBitness, etc macros appropriately. Like I said, the above isn't working completely, but it is as close as I've managed to come so far to what I need. Macro values in the .vsprops files should be: PlatformArch: x86 or ia64 (Itanium) PlatformBitness 32 or 64 SecureSCLValue 0 or 1 (always 1 for debug builds) BoostConfiguration debug or release (lower-case of $(ConfigurationName)) Here's the build log for one of the failing combinations. The 1> is the thread identifier added by the Visual Studio build engine running in multithreaded mode: 1>building test shared shared 1>c:/code/Version 9/boost/tools/build/v2/build\virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target 1>error: Duplicate name of actual target: <pstage\lib>boost_prg_exec_monitor-vc90-mt-1_35.dll 1>error: previous virtual target { common%common.copy-boost_prg_exec_monitor-vc90-mt-1_35.dll.SHARED_LIB { msvc%msvc.link.dll-boost_prg_exec_monitor-vc90-mt-1_35.dll.SHARED_LIB { msvc%msvc.compile.c++-execution_monitor.obj.OBJ { execution_monitor.cpp.CPP } } { msvc%msvc.compile.c++-debug.obj.OBJ { debug.cpp.CPP } } { msvc%msvc.compile.c++-cpp_main.obj.OBJ { cpp_main.cpp.CPP } } } } 1>error: created from ./stage-proper 1>error: another virtual target { common%common.copy-boost_prg_exec_monitor-vc90-mt-1_35.dll.SHARED_LIB { msvc%msvc.link.dll-boost_prg_exec_monitor-vc90-mt-1_35.dll.SHARED_LIB { msvc%msvc.compile.c++-execution_monitor.obj.OBJ { execution_monitor.cpp.CPP } } { msvc%msvc.compile.c++-debug.obj.OBJ { debug.cpp.CPP } } { msvc%msvc.compile.c++-cpp_main.obj.OBJ { cpp_main.cpp.CPP } } } } 1>error: created from ./stage-proper 1>error: added properties: none 1>error: removed properties: <address-model>32 <architecture>x86 1>c:/code/Version 9/boost/tools/build/v2/build\virtual-target.jam:453: in actualize-no-scanner from module object(file-target)@695 1>c:/code/Version 9/boost/tools/build/v2/build\virtual-target.jam:118: in object(file-target)@695.actualize from module object(file-target)@695 1>c:/code/Version 9/boost/tools/build/v2\build-system.jam:675: in load from module build-system 1>c:\code\Version 9\boost\tools\build\v2/kernel\modules.jam:267: in import from module modules 1>c:\code\Version 9\boost\tools\build\v2/kernel/bootstrap.jam:132: in boost-build from module 1>c:\code\Version 9\boost\boost-build.jam:11: in module scope from module 1>Project : error PRJ0019: A tool returned an error code from "Performing Makefile project actions"

I haven't tested this fully yet, but isn't it as simple as getting the command line for the architecture you want and then running the same command.

So I got a command line from: Visual Studio 2008 x64 Win64 Command Prompt And Visual Studio 2008 Command Prompt Did you actually get 64-bit libraries? When I tried this approach with 1.35 RC2 I got identical binary files from both sets of builds. Using Win2003 and XP Pro, both 32- and 64-bit platforms.

Are you saying that the difference in syntax is significant? Is the line you quoted, presumably prefixed with "bjam ", supposed to be sufficient? Sure enough, I can build up a command using the bare property names (no msvc/) and it seems to work.... C:\code\Version 9\boost>bjam toolset=msvc-9.0 address-model=64 link=static,shared runtime-link=static,shared --with-regex --with-test --build-dir="C:\code\my-solution-root\Release-x64\boost" release stage I have a difficult time picturing why this works and the other doesn't but hey, if this is the incantation that works, this is the incantation I'll use. Plug it into the Visual Studio "Makefile" project build, rebuild, and clean command line textboxes, with suitable macro substitutions, and I should have the automation I need. Since this builds all the sensible combinations and skips the stupid ones there's no need for the "for loop" mechanism in my earlier post. But if you want to cherry-pick configurations to save time and/or space, that mechanism will still work. I still need to tease out the magic words to control the other optimization features but there are clues in the archives for those. I'll also have to cobble together a mechanism to make bjam use the modified compiler driver when DevPartner is active but that's a job for another day. -----Original Message----- From: Vladimir Prus [mailto:vladimir@codesourcery.com] Sent: Wednesday, June 25, 2008 6:33 AM To: boost@lists.boost.org Subject: Re: [boost] [getting started] Windows 64-bit builds? Stephen Nuchia wrote:

...

2. Please get someone to tell me the answer to the question that you want the guide to answer ;-)

I've found that you need --toolset=msvc msvc/architecture=x86/address-model=64

Uh-oh! This should be: toolset=msvc address-model=64 at least that's what folks were using to successfully build 64-bit binaries. - Volodya

Vladimir Prus wrote:

Stephen Nuchia wrote:

...

Are you saying that the difference in syntax is significant? Is the line you quoted, presumably prefixed with "bjam ", supposed to be sufficient?

Yes. To clarify, you've originally mentioned:

--toolset=msvc msvc/architecture=x86/address-model=64

and "--toolset=msvc" is exactly same as "toolset=msvc", so the above is:

toolset=msvc toolset=msvc/architecture=x86/address-model=64

and it's requesting two build everything twice -- in 32-bit mode, and 64-bit mode, and given that library filenames are the same, naturally things don't really work well.

This is yet another example how "--toolset" confuses everybody.

I seriously doubt the additional "--" are the real source of the confusion in this case. However, feel free to remove it if you think it's more confusing than helpful. Just open a ticket for me to update the getting started guide appropriately. Actually, we probably should just deprecate it (i.e. only remove its documentation but not the implementation) for backward compatibility and so people finding old web pages and suchlike will not fail to build too early on :-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com