On Tuesday 29 June 2010 22:25:44 Cactus wrote: > On Jun 29, 8:38 pm, Jason Moxham <ja...@njkfrudils.plus.com> wrote: > > 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 big issue for me here is not making the changes on Windows but in > working out what has happened on Linux and what this means for the > Windows build. > > If the changes are properly documented before they are done the effort > would not then be large, albeit a bit tedious tedious. >
I will try to post to the list all relevant changes so you can get the heads up. Some of the changes I will do when I get a spare hour or two , I wouldn't do them otherwise as they are not terribly important , but it can make work for you which could be seen as pretty pointless. > > 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. > > Much as I would like to see this, I agree that it would involve a huge > effort. > > > 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. > > I am not sure about this one as I don't fully understand the > capabilities you envisage. > I mean a script which would select a code path based on cpu , and then use cl.exe to compile and link everything in that path. The resultant library should be just as good for the user , but for the developer many it would be a pain to use. > > 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. > > This is attractive as it would maintain a native Windows build > capability. > > > 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). > > I am far from convinced that this will provide a decent native Windows > build. > > Turning WIndows into a poor man's version of Linux does not appeal to > me as it almost always involves abandoning Windows conventions, For > example, non standard installation directories have to be used to > avoid spaces in paths whiich almost invaraibly kill Unix tools. > > > 5) Just the leave the system as it is. > > > > My thoughts are these > > 1) Insane > > Agreed. > > > 2) The present configure.bat,make.bat emulate what it would achieve , but > > would make development on a windows system awkward. > > It would be hard to emulate the FAT build but I have often wondered > whether it would be possible to automate the generation of *.vcproj > files from Unix makefiles. > I have not considered FAT builds. > > 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 > > I have never used CMAKE but it has a strong following. I have never used it either :) > > > 4) We should be able to do this with a few weeks hacking > > Can it be done without turning Windows into a poor man's Linux? > > > 5) Will keep Brian busy :) > > That depends on what is now planned :-) > > > 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. > > But the proliferation of assembler is by far the biggest task that I > face as it petty well always involves a partial rewrite. > I had always assumed it was fairly painless , as you always manage to convert them within a day or two :) > Although some conversions are easy, the more 'serious' assembler files > with a lot of macros and repeated code sequences are often very > difficult and very error prone during conversion. > > Bill and I started with the intent of having one set of assembler > files to support both Linux and Windows but we gave up as the > constraints imposed by Windows x64 calling conventions are difficult > to accommodate without reducing performance on Linux. > > Brian -- 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.
