On Sat, 9 Jun 2012 20:48:13 +0300
degski <deg...@gmail.com> wrote:
> >
> >
> > I am not pushing to move away from YASM but if we want to reduce our
> > dependence on non-native tools and YASM in particular, then using
> > GAS on Unix/Linux and MASM on Windows makes sense as this would
> > allow 'out of the box' builds on both Unix/Linux and Windows.
> >
>
> It is already not possible to build MPIR (or anything for that matter
> - out-of-the-box - ). I don't know of any version of windows that
> comes with a pre-installed version of visual studio). In reality
> there are plenty of things on windows you cannot do out-of-the-box.
> you'll need to download a compiler, install it and configure it...
Hi Degski,
You are right - the main point here is that of avoiding the need to
augment MSVC by adding non-native tools (MASM is installed as a part
of Visual Studio).
> My feeling is that this is completely beside the point, YASM is free
> software, it's very small, and comes (thanks to Brian) with extremely
> simple and clear instructions what to do in order to make it work
> with VS.
The problem is that the YASM integration into Visual Studio is very
limited and does not allow the full potential of Visual Studio to be
harnessed during development and debugging.
This is not a problem for people who only expect to compile MPIR but
for my use it is a significant impediment in the ongoing development
process. YASM is a good compromise while it is used for both
Unix/Linux and Windows builds but once this commonality is given up,
the use of YASM on Windows alone is then open to question given the
native MASM assembler and its full integration into Visual Studio.
> Those users interested in compiling their own version of GMP will
> have by definition a level of computer-literacy that enables them to
> complete the instructions for installing YASM without issue (if not,
> it will prepare them for the difficulties ahead)...
>
> Other than to keep oneselves busy, I don't see what a move to MASM
> would bring, although at the end I don't care, as if all goes well,
> the resulting machine-code will be the same.
It would be different in detail but functionally the same :-)
> My 2 cents would be that if it ain't broken don't fix it. YASM is
> actively developed and supported, it can only get better! And not
> unimportant, the fact that YASM is used for compiling MPIR will
> certainly motivate the YASM team to keep doing what they are doing
> and doing it well, in the same way SAGE sparks enthousiasm in the
> MPIR-team.
YASM is first class - it is Microsoft has been less than helpful in
providing support for non-native tool integration in Visual Studio. In
VS 2008 there was an easy way to add tools but they withdrew this in
VS 2010. They said that they might try to make this easier in VS 2012
but this hasn't happened :-( So YASM integration remains less than
ideal.
On a more positive note, VS 2012 build files can be reverted back to VS
2010 very easily so the old problem of downgrading builds to earlier
Visual Studio versions will be much less of a problem.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@googlegroups.com.
To unsubscribe from this group, send email to
mpir-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
