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.
> 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.
> 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.
> 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.
> 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.
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.
