Re: [boost] [context] Don't hard-code the assembler

AMDG On 04/01/2014 11:13 PM, Oliver Kowalke wrote:

2014-04-02 0:20 GMT+02:00 Steven Watanabe :

...

I think I'd prefer it if Boost.Context just gave an error if I use a toolset that it doesn't support, instead of trying (and failing badly) to switch silently to a different toolset.

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?

...

...

On Windows MASM is used to compile boost.context - it was shipped with MS Visual Studio an at some point MS decided to move it from the MS Visual Studio to the MS WDK.

It's still installed along with Visual Studio.

masm64 too?

masm used to be a standalone tool, but was integrated into visual studio (in vc6, I think). The current version is no longer distributed separately, although it is also included in a few other packages as well (including the WDK). I've seen claims on the internet that Microsoft stopped shipping masm with Visual Studio, but AFAICT, it simply isn't true. 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.

...

- 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.

...

- If the assembler has a name other then as, it cannot be used, even if it would actually work. This is especially likely to be a problem for cross compiling.

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. 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. In Christ, Steven Watanabe