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

Subject: Re: [boost] [context] Don't hard-code the assembler
From: Jürgen Hunold (jhunold_at_[hidden])
Date: 2014-04-08 03:30:19

Hi Oliver,

Am Dienstag, 8. April 2014, 06:36:19 schrieb pmenso57_at_[hidden]:
> > From: "Oliver Kowalke" <oliver.kowalke_at_[hidden]>
> > 
> > > 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).

The central point is "on the platform". Requiring MASM does not work when 
cross-compiling (mostly form Linux or some other *nix). And this is something 
which is demanded by more and more users. 

> > why must be the different assembler syntax' of the different assembler
> > tools be supported?
> 
> I am no expert when it comes to assembler variations, but I'd rather not
> have to have a dependency on MS tools.  VC++ et al being the "standard
> tools on the platform" is part of the problem, not something to be
> encouraged.

Yes, a lot of people are trying to switch from vc++ to gcc/clang for a lot of 
reasons. This affects not only Boost, but every popular cross platform 
framework.

Maybe you should look at "support" and "maintenance" from another point of 
view. I think it is a sure bet that the question "why can't I use gnu 
assembler for context and why can't I cross-compile from my favourite platform 
using gcc/clang" will crop up every few months. See the aforementioned

 https://svn.boost.org/trac/boost/ticket/7262

and the mailing archives. This is at least the 4. or 5. discussion about 
supporting gnu assembler on windows and won't be the last. What about simply 
accepting the fact that this is what more and more users *need* and *want* and 
provide at least the feature most demanded? This would save everyone a lot of  
timeand effort in the long run.
I can understand you can't provide corde for assembler variant out there, but 
supporting the two most important ones on Windows, including one free 
implementation, will make a lot of people happy. And I really doubt there are 
gnu incompatible *nix assemblers out there any more. And people using obsolete 
compilers and tools have hard times ahead for a lot of other reasons...

And no, I don't use context, I'm just tired of ignoring build errors when 
using mingw or not running vcvarsall.bat. And ignoring discussions wasting 
everyones time.

And don't underestimate the community. As soon as some working code is 
available, patches tend be committed. Been there, seen that :-)

Yours,

Jürgen
-- 
* Dipl.-Math. Jürgen Hunold  ! 
* voice: ++49 4257 300       ! Fährstraße 1
* fax  : ++49 4257 300       ! 31609 Balge/Sebbenhausen
* jhunold_at_gmx.eu             ! Germany