On Friday 25 June 2010 20:16:15 Jason Moxham wrote: > Hi > > These cpu's also have no support from gcc , so again I think we should > certainly remove them > > gmicro > i860 > ibm032 or 032 or ROMP > uxp or xp fujitsu 32bit vector supercomputer >
I have removed all traces of the above cpus and I will start to chop out the old OS'es . Note: this does not mean that we will not run under these OS'es , it just means that any special conditions for them are removed . Some of these special conditions are for broken installs or very old versions which were missing certain crucial header files etc , so later versions may work , but I would not count on it , and if they dont then tough :) Thinking about what other changes I would like to make to simplify things a bit , I released that most of the other changes would involve Brian making similar changes to the vcproj files . A few of the simpler name changes I am sure I can do a simple text replacement of the vcproj files, but most of the other stuff would need Brian's involvement. So it seems that the best course forward to avoid this duplication of effort is to get the windows port following the unix one automatically. The justification for simplifying our build system is that 50% of errors are build system related , and unfortunately autotools is a very poor design , it requires you to understand it internals to use it. 1) write our own build system starting with x86 and work thru the other major cpu's/OSes one at a time. This is TOO much work , we are not taking advantage of other peoples work on "boring" stuff , MPIR is about math not build systems. 2) We could write a simple script which does a basic build , but it would make windows a second class build environment unless we re-implement most features of a make system.There are two aspects to this , 1) to get the build optimal and 2) be able to debug and develop with windows. 3) We could convert to eg) cmake which supports unix and windows , this appears to be the most attractive option , this would take a fair amount of time. cmake produces native vcproj files for windows and makefiles for linux , so both camp's would be in their NATIVE elements. 4) Get autotools to run NATIVE in windows with MSVC . What I have in mind is really a trick , there are two parts to it , 1) get it use cl.exe instead of gcc.exe 2) hide the fact that we are running under another shell. autotools can run cl.exe , no problem , just like it can run cc or icc , the options are a little different , but a script can easily take care of that (as long as everything is one-to-one) , once we have this bit , then we could get a MSVC compile under cygwin or minGW . The next stage is to have a "hidden install" of minGW so we can run autotools, (just like we do for yasm under linux). 5) Just the leave the system as it is. My thoughts are these 1) Insane 2) The present configure.bat,make.bat emulate what it would achieve , but would make development on a windows system awkward. 3) This seems like the best long term solution , to use a build system which will handle all modern OS'es , but it means a lot of work 4) We should be able to do this with a few weeks hacking 5) Will keep Brian busy :) Note: this does not address the issue that the assembler code for linux and windows are different , but I dont believe this to be a major obstical at the moment. When I get my Windows box back , assuming they managed to fix it this time , then I will try for 4) , I'm sure other projects could also benefit from this(ie sage) Jason -- 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.
