I remember adding some of these thinking that we just needed them to "pass through". Basically we were using names that it was unfamiliar with. So it would fail. Adding them here allowed our specialised names to pass through. That was the reasoning anyhow.
Bill. On 27 August 2010 20:19, Jason <ja...@njkfrudils.plus.com> wrote: > 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. > > -- 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.
