[mpir-devel] detecting CPU type, CFLAGS, MPN_PATH

2012-05-22 Thread Jeroen Demeyer
Within the Sage project, we discovered several issues with the CPU/CFLAGS/MPN_PATH configuration code in MPIR-2.4.0. The code mostly works well, but there are a few things I would like to change. I would also like to add a configuration option to build a generic binary meaning one which would

Re: [mpir-devel] Rationale for using YASM?

2012-05-22 Thread Brian Gladman
On Tue, 22 May 2012 11:14:51 +0200 Jeroen Demeyer jdeme...@cage.ugent.be wrote: What is the reason that MPIR uses yasm to build *some* of its assembly files? It seems that most assembly files are built using gcc, i.e. the system assembler. Why use two different assemblers? Originally it was

Re: [mpir-devel] detecting CPU type, CFLAGS, MPN_PATH

2012-05-22 Thread Bill Hart
On 22 May 2012 10:10, Jeroen Demeyer jdeme...@cage.ugent.be wrote: Within the Sage project, we discovered several issues with the CPU/CFLAGS/MPN_PATH configuration code in MPIR-2.4.0.  The code mostly works well, but there are a few things I would like to change. I would also like to add a

Re: [mpir-devel] Rationale for using YASM?

2012-05-22 Thread Bill Hart
I agree with that explanation. However, I should add that it is largely for historical reasons. MPIR originally planned to support MSVC out-of-the-box (as did Sage once). One reason for this is that many Windows developers use MSVC. Brian Gladman has been successfully providing that ability

Re: [mpir-devel] Rationale for using YASM?

2012-05-22 Thread Brian Gladman
On Tue, 22 May 2012 14:37:26 +0100 Bill Hart goodwillh...@googlemail.com wrote: I agree with that explanation. However, I should add that it is largely for historical reasons. MPIR originally planned to support MSVC out-of-the-box (as did Sage once). One reason for this is that many Windows

Re: [mpir-devel] Rationale for using YASM?

2012-05-22 Thread Brian Gladman
On Tue, 22 May 2012 15:19:52 +0100 Bill Hart goodwillh...@googlemail.com wrote: Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the linux assembly code. So indeed, for MinGW support, we probably have little choice but to use a portable assembler. So it looks like we are

Re: [mpir-devel] Rationale for using YASM?

2012-05-22 Thread Brian Gladman
On Tue, 22 May 2012 16:53:07 +0100 Bill Hart goodwillh...@googlemail.com wrote: On 22 May 2012 16:37, Brian Gladman b...@gladman.plus.com wrote: On Tue, 22 May 2012 15:19:52 +0100 Bill Hart goodwillh...@googlemail.com wrote: Well spotted. Indeed, MinGW64 uses the Windows assembly code,

Re: [mpir-devel] Rationale for using YASM?

2012-05-22 Thread Bill Hart
On Tuesday, 22 May 2012, Brian Gladman b...@gladman.plus.com wrote: On Tue, 22 May 2012 16:53:07 +0100 Bill Hart goodwillh...@googlemail.com wrote: On 22 May 2012 16:37, Brian Gladman b...@gladman.plus.com wrote: On Tue, 22 May 2012 15:19:52 +0100 Bill Hart goodwillh...@googlemail.com

Re: [mpir-devel] Rationale for using YASM?

2012-05-22 Thread Bill Hart
On Tuesday, 22 May 2012, Bill Hart goodwillh...@googlemail.com wrote: On Tuesday, 22 May 2012, Brian Gladman b...@gladman.plus.com wrote: On Tue, 22 May 2012 16:53:07 +0100 Bill Hart goodwillh...@googlemail.com wrote: On 22 May 2012 16:37, Brian Gladman b...@gladman.plus.com wrote: On

Re: [mpir-devel] Rationale for using YASM?

2012-05-22 Thread Jeroen Demeyer
On 2012-05-22 15:37, Bill Hart wrote: We could then ditch building Yasm on Linux, which would save some headaches for Sage. I don't really think that yasm is a problem for Sage. It's true that sometimes a Sage build might build because of a problem with yasm, but it's more because MPIR/YASM is