Doing the same for configfsf.sub we get
diff config-5ac8187868dd8955d5051dfb4ff56e69abe80dbd/config.sub mpir/trunk/configfsf.sub 4a5,6 > # > # Copyright 2008 William Hart 10a13,14 > # In particular, this version of the file has been modified for the MPIR > # program. 24,25c28,29 < # Foundation, Inc., 59 Temple Place - Suite 330, < # Boston, MA 02111-1307, USA. --- > # Foundation, Inc., 51 Franklin Street, Fifth Floor, > # Boston, MA 02110-1301, USA. 303c307,308 < | clipper-* | cydra-* \ --- > | core2-* \ > | clipper-* | cydra-* \ 330c335,336 < | none-* | np1-* | nv1-* | ns16k-* | ns32k-* \ --- > | nocona-* \ > | none-* | np1-* | nv1-* | ns16k-* | ns32k-* \ 332,334c338,342 < | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \ < | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \ < | pyramid-* \ --- > | pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \ > | pentium4-* \ > | powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \ > | prescott-* \ > | pyramid-* \ 444c452,455 < cray | j90) --- > core-*) > basic_machine=i686-`echo $basic_machine | sed 's/^[^-]*-//'` > ;; > cray | j90) 793c804 < pentiumpro | p6 | 6x86 | athlon | athlon_*) --- > pentiumpro | p6 | 6x86 | athlon | k7 | k7_* |athlon_*) 799,801d809 < pentium4) < basic_machine=i786-pc < ;; 805c813 < pentiumpro-* | p6-* | 6x86-* | athlon-*) --- > pentiumpro-* | p6-* | 6x86-* | athlon-* | k7-*) 811,813d818 < pentium4-*) < basic_machine=i786-`echo $basic_machine | sed 's/^[^-]*-//'` < ;; 1102c1107 < *-unknown) --- > *-unknown | *-pc | *-apple) You can see that except for the very last diff , the only changes are that specific cpu models have been added , this is the wrong place to add them , and anyway some other models are missing and we know it works on all of them. So the only thing we have to worry about is the "unknown | pc | apple " bit. They dont have this anyway in the latest , so we may need to add it back in. The pc bit was added in svn rev 1805 following this thread http://groups.google.com/group/mpir- devel/browse_thread/thread/eeafdd119660cad9/6ecdea0122067d44?lnk=gst&q=*- pc+allready#6ecdea0122067d44 Which was a configure failure on a 32bit ASUS EE PC with atom cpu. I'll leave out the change for the moment , and see if it still works. If it doesn't then we should push this change upstream. Jason On Friday 27 August 2010 19:25:27 Jason wrote: > Hi > > Hopefully updating configfsf.guess and sub will help with the recognition > of mingw64 and possible some other system where we dont test > > > diff config-5ac8187868dd8955d5051dfb4ff56e69abe80dbd/config.guess > mpir/trunk/configfsf.guess > 6c6 > < timestamp='2004-03-12' > --- > > > timestamp='2004-10-07' > > 20c20 > < # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, > USA. --- > > > # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > > 02110-1301, > > USA. > 662c662,663 > < if echo __LP64__ | (CCOPTS= $CC_FOR_BUILD -E -) | grep __LP64__ > > >/dev/null > > --- > > > echo "__LP64__" > $dummy.c > > if (CCOPTS= $CC_FOR_BUILD -E $dummy.c) | grep __LP64__ > > >/dev/null > > This shows we have mode no significant changes to configfsf.guess and I can > just replace it with the latest version , which has 6 years !!!! of > changes. > > configfsf.sub looks more difficult > > Jason > > On Friday 27 August 2010 16:18:48 Jason wrote: > > Hi > > > > The mingw64 build mostly works now , but there are a few minor problems > > still to sort out. In the x86_64w directory we should mirror the x86_64 > > directory so we can have builds for the atom , netburst etc . This should > > not involve any assembler conversions as so far I dont think there is any > > specific code for these cpu's. The fat build doesn't work yet , and we > > have duplicate symbols defined on the shared lib build. T-local test > > fails , and the mingw32 build is I suspect broken , as our config.guess > > cant distinguish between mingw32 and mingw64 > > > > Jason > > > > On Thursday 19 August 2010 15:08:48 Bill Hart wrote: > > > Yes, there is strong demand for a 'make' based solution on Windows, > > > but using MSVC as the compiler. > > > > > > If you would like to give it a go, I know lots of people would be very > > > appreciative. Jason has put in a kind of configure/make type thing for > > > Windows. So it is there already to some extent. > > > > > > Of course for some people, maintaining the visual IDE solutions is > > > absolutely imperative, and Brian has been doing this for the latest > > > version of MSVC for a long time. So that will still be needed. It also > > > makes writing a 'make' based solution about 1000 times easier. > > > > > > Bill. > > > > > > On 19 August 2010 12:20, degski <deg...@gmail.com> wrote: > > > > Hi Cactus, > > > > > > > >> The real problem here is that nobody is willing to put in the effort > > > >> involved in maintaining the Visual Studio 2008 build. > > > > > > > > Maybe that should read ...is that nobody, feeling qualified, is > > > > willing to... I would not mind to chip in, but like it says, do I > > > > think I can deliver? > > > > > > > >> Its essentially the same problem. > > > >> > > > >> There is strong demand for a 'make' based MPIR build on Windows but, > > > >> again, nobody has volunteered to develop this. > > > > > > > > Well, yes, but once realized, maintainability will go up a lot and > > > > the move to VS2012 or whatever can be smooth and painless. > > > > > > > > I guess it would require somebody with a good understanding of the > > > > build process required, who could give input to identifying the > > > > difficulties (I mean, put on "paper") in creating this Windows build > > > > process. In the SWI-Prolog build process, the main difficulty is/was > > > > dealing with the different build environments, once defined and > > > > (pre-)configuration automated, it works quite well. > > > > > > > > Like you say, it seems most agree that the project approach is hard > > > > to maintain going forward and that "There is strong demand for a > > > > 'make' based MPIR build on Windows". > > > > > > > > Cheers > > > > > > > > > > > > degski > > > > > > > > -- > > > > Eric Schmidt, the chief executive of Google, has issued a stark > > > > warning over the amount of personal data people leave on the internet > > > > and suggested that many of them will be forced one day to change > > > > their names in order to escape their cyber past. > > > > > > > > The Independent, 18th August 2010 > > > > > > > > -- > > > > You received this message because you are subscribed to the Google > > > > Groups "mpir-devel" group. To post to this group, send email to > > > > mpir-de...@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. -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@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.
