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.
