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

Subject: Re: [boost] [context] Don't hard-code the assembler
From: Steven Watanabe (watanabesj_at_[hidden])
Date: 2014-04-07 22:13:30

AMDG

On 04/01/2014 11:13 PM, Oliver Kowalke wrote:
> 2014-04-02 0:20 GMT+02:00 Steven Watanabe <watanabesj_at_[hidden]>:
>> 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