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

Subject: Re: [boost] [context] Don't hard-code the assembler
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2014-04-08 02:27:43

2014-04-08 4:13 GMT+02:00 Steven Watanabe <watanabesj_at_[hidden]>:

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