2014-04-08 4:13 GMT+02:00 Steven Watanabe
it does not switch to another toolset - boost.context contains assembler code only and the convention is:
- on i386-Windows its uses MASM - on x86_64-Windows its uses MASM64 - on arm-Windows armasm - on all other platforms GNU as
How is this not switching to a different toolset?
related to combination of architectue/ABI/address-model/binary-format - only one toolset
masm64 too?
masm used to be a standalone tool, but was integrated into visual studio (in vc6, I think).
for MSVC6 32bit masm wash shipped with
The current version is no longer distributed separately, although it is also included in a few other packages as well (including the WDK).
yes
I've seen claims on the internet that Microsoft stopped shipping masm with Visual Studio
that was my information too
It's definitely included in VC Express (I checked all the versions I have installed, 9.0, 10.0, 11.0, and 12.0), and I can't believe that Microsoft would leave it out of the paid versions, if they include it in the free version.
I've to rely on the information I get from other developers
- With <toolset>msvc, the assembler can't be found automatically, even though Boost.Build already knows how to find it.
hmm - it works for me - 'b2 toolset=msvc-10.0' builds boost.context on Win32
Meaning that you've added masm to your PATH.
I compile boost on Windows+MSVC always inside the MSVC-cmd prompt
what would be a solution? If I would let the toolset choose the assembler tool I would be forced to support the different syntax of those assembler tools (which would be a lot if you know how many assemblers are available).
I think you're vastly exaggerating the problem. You don't need to support every assembler in existence. Most of the assemblers out there are standalone tools that have nothing to do with the toolset, and are thus completely irrelevant. msvc, gcc, clang, intel, and darwin, should all be okay, and these are by far the most common and the only toolsets that are run in the regression matrix. tasm is obsolete, but claims to be compatible with masm. I couldn't find any information on xlc, sun, pathscale, or pgi.
and what is the conclusion regarding to xlc, sun, pathscale etc.?
The only real problem that I'm aware of is MinGW, which you should support directly anyway. See https://svn.boost.org/trac/boost/ticket/7262 which (a) describes a concrete use case where your proposed solution of using masm cannot possibly work, and (b) includes a patch.
that's the problem! - MinGW's assembler tool does have a different syntax than MASM. The defacto standard on Windows is MASM - why not use the standard tool on the platform to compile the object files (boost.context consists of assembler only). why must be the different assembler syntax' of the different assembler tools be supported?