14257
Comment: removed spurious space
|
14965
|
Deletions are marked like this. | Additions are marked like this. |
Line 26: | Line 26: |
|| [[http://perso.ens-lyon.fr/damien.stehle/english.html#software | fplll]] || XXXX || || | || [[http://perso.ens-lyon.fr/damien.stehle/english.html#software | fplll]] || 2.1.6-20071129.p1 || no Windows port, needs some specialized math functions, but should be a relatively easy port. Upstream will likely merge Windows patches [[worry?]] || |
Line 34: | Line 34: |
|| gfan || 0.2.2.p2 || unclear how hard the port will be, but shouldn't be too hard. [[we should upgrade to 0.2.3 first]]. Some more remarks: gfan requires argv[0] to switch to the right computation. I.e. during installation the following is executed: "ln -s gfan gfan_weightvector". This should be portable, but symlinks can be problematic on Windows. || || givaro || 3.2.6.p6 || no port exists, C++ code uses templates and it migt. be a little tricky to get right. Upstream welcomes patches [[could be hard.]] || || gnutls || 2.2.1.p1 || Shortly the spkgs for libgpg_error, libgcrypt and opencdk will disappear since gnutls now includes copies of them. gnutls has build support for 32 bit MSVC, the feasability of the 64 bit build needs to be investigated. Problems might crop up with inline assembly. [[maybe there is a native windows library that provides similar functionality. This is only needed so Twisted works with Python, and I'm sure that is already very well supported.]] || |
|| [[http://www.math.tu-berlin.de/~jensen/software/gfan/gfan.html | gfan]] || 0.2.2.p2 || unclear how hard the port will be, but shouldn't be too hard. [[we should upgrade to 0.2.3 first]]. Some more remarks: gfan requires argv[0] to switch to the right computation. I.e. during installation the following is executed: "ln -s gfan gfan_weightvector". This should be portable, but symlinks can be problematic on Windows. || || [[http://ljk.imag.fr/CASYS/LOGICIELS/givaro/ | givaro]] || 3.2.6.p6 || no port exists, C++ code uses templates and it migt. be a little tricky to get right. Upstream welcomes patches [[could be hard.]] || || [[http://www.gnu.org/software/glpk/glpk.html | glpk]] || XXXX || || || [[http://www.gnu.org/software/gnutls/ | gnutls]] || 2.2.1.p1 || Shortly the spkgs for libgpg_error, libgcrypt and opencdk will disappear since gnutls now includes copies of them. gnutls has build support for 32 bit MSVC, the feasability of the 64 bit build needs to be investigated. Problems might crop up with inline assembly. [[maybe there is a native windows library that provides similar functionality. This is only needed so Twisted works with Python, and I'm sure that is already very well supported.]] || |
Line 38: | Line 39: |
|| iml || 1.0.1.p9 || no port exists, but it should be pretty straight forward. [[this won't be hard, since iml is just clean C code, mostly concerned with mat]] || || ipython || 0.8.1.p1 || should work fine with MSVC [[definitely will work fine.]] || |
|| [[http://www.cs.uwaterloo.ca/~astorjoh/iml.html | iml]] || 1.0.1.p9 || no port exists, but it should be pretty straight forward. [[this won't be hard, since iml is just clean C code, mostly concerned with mat]] || || [[http://ipython.scipy.org/moin/ | ipython]] || 0.8.1.p1 || should work fine with MSVC [[definitely will work fine.]] || |
Line 41: | Line 42: |
|| jmol || 11.5.2.p1 || pure java, no portability issues, large community of users on Windows || || lapack || 20071123.p0 || Works out of the box with GNU make. || || lcalc || 20070107.p1 || somewhat crafty C code, ugly hacks in the user interface, but should be portable to MSVC. Builds fine under Cygwin || || libfplll || 2.1.6-20071129.p1 || no Windows port, needs some specialized math functions, but should be a relatively easy port. Upstream will likely merge Windows patches [[worry?]] || || libgpg_error || 1.6.p0 || || || libgcrypt || 1.4.0.p0 || || || linbox || 20070915.p5 || this will be some heavy lifting, mostly due to some heavy templated code. Upstream is willing to merge and help out. || || libpng || 1.2.22.p5 || port exists: http://gnuwin32.sourceforge.net/packages/libpng.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves. In this case it seems likely that somebody else has done a proper Windows port. We might also be able to uses the system's library, but there might be issues with featurs, i.e. IE's libpng is supposed to be fairly bad. [[yep, something builtin to windows might be useful.]] || || matplotlib || 0.91.1.p3 || should work with MSVC, more investigation is needed [[I'm sure this will work -- it is also part of what the enthought people distribute for windows.]] || || maxima || 5.13.0.p2 || Should build fine with Clisp, Windows binary package exists. || || mercurial || 0.9.5.p0 || some C extensions, maybe some portability issues, might need some TLC for various config issues || |
|| [[http://jinja.pocoo.org/ | jinja]] || XXXX || || || [[http://jmol.sourceforge.net/ | jmol]] || 11.5.2.p1 || pure java, no portability issues, large community of users on Windows || || [[http://www.math.union.edu/~dpvc/jsMath/ | jsmath]] || XXXX || || || [[http://www.netlib.org/lapack/ | lapack]] || 20071123.p0 || Works out of the box with GNU make. || || [[http://pmmac03.math.uwaterloo.ca/~mrubinst/L_function_public/CODE/ | lcalc]] || 20070107.p1 || somewhat crafty C code, ugly hacks in the user interface, but should be portable to MSVC. Builds fine under Cygwin || || [[http://directory.fsf.org/project/libgcrypt/ | libgcrypt]] || 1.4.0.p0 || || || [[http://www.gnupg.org/related_software/libgpg-error/ | libgpg_error]] || 1.6.p0 || || || [[http://www.libpng.org/pub/png/libpng.html | libpng]] || 1.2.22.p5 || port exists: http://gnuwin32.sourceforge.net/packages/libpng.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves. In this case it seems likely that somebody else has done a proper Windows port. We might also be able to uses the system's library, but there might be issues with featurs, i.e. IE's libpng is supposed to be fairly bad. [[yep, something builtin to windows might be useful.]] || || [[http://www.linalg.org/ | linbox]] || 20070915.p5 || this will be some heavy lifting, mostly due to some heavy templated code. Upstream is willing to merge and help out. || || [[http://matplotlib.sourceforge.net/ | matplotlib]] || 0.91.1.p3 || should work with MSVC, more investigation is needed [[I'm sure this will work -- it is also part of what the enthought people distribute for windows.]] || || [[http://maxima.sourceforge.net/ | maxima]] || 5.13.0.p2 || Should build fine with Clisp, Windows binary package exists. || || [[http://mercurial.selenic.com/wiki/ | mercurial]] || 0.9.5.p0 || some C extensions, maybe some portability issues, might need some TLC for various config issues || |
Line 53: | Line 55: |
|| mpfi || 1.3.4-cvs20071125.p5 || depends on mpfr and gmp, pure C library. Port is simple and will probably be merged upstream || | || [[http://perso.ens-lyon.fr/nathalie.revol/software.html | mpfi]] || 1.3.4-cvs20071125.p5 || depends on mpfr and gmp, pure C library. Port is simple and will probably be merged upstream || || [[http://mpir.org/ | mpir]] || XXXX || || |
Line 83: | Line 86: |
|| ecm || 6.1.3 || no Windows port, but C, potentially issues with threading. Upstream ecm-6.2 has MSVC project by Brian Gladman - upgrading evm to the 6.2 release is #3237 || || gmp || 4.2.1.p12 || port by Brian Gladman exists - http://fp.gladman.plus.com/computing/gmp4win.htm. The main disadvantage is that the build is done via project file. A fallback option is to use the pure C fall back code via MSVC or Intel's C compiler since MSVC doesn't do the right inline assembly. Brian's gmp works perfectly in Win64 mode. [[good!]]. MPIR will have full MSVC project support || || gsl || 1.10.p0 || port exists: http://gnuwin32.sourceforge.net/packages/gsl.htm. Brian Gladman also maintains a native MSVC port, 32 & 64 bit. || || libm4ri || 20071224.p1 || MSVC and SunForte port done by Martin Albrecht and in upstream. Upgrade ticket is #3204 || || mpfr || 2.3.1 || pure C, Windows make file support welcome upstream, depends on gmp. MSVC project by Brian Gladman exists and is recommended by upstream || |
|| [[https://gforge.inria.fr/projects/ecm/ | ecm]] || 6.1.3 || no Windows port, but C, potentially issues with threading. Upstream ecm-6.2 has MSVC project by Brian Gladman - upgrading evm to the 6.2 release is #3237 || || [[http://www.gnu.org/software/gsl/ | gsl]] || 1.10.p0 || port exists: http://gnuwin32.sourceforge.net/packages/gsl.htm. Brian Gladman also maintains a native MSVC port, 32 & 64 bit. || || [[http://m4ri.sagemath.org/ | m4ri]] || 20071224.p1 || MSVC and SunForte port done by Martin Albrecht and in upstream. Upgrade ticket is #3204 || || [[http://www.mpfr.org/ | mpfr]] || 2.3.1 || pure C, Windows make file support welcome upstream, depends on gmp. MSVC project by Brian Gladman exists and is recommended by upstream || |
This page is part of the Sage on Windows port.
Package Analysis
Below you will find a list of packages in Sage as well as remarks on issues that will potentially come up during the Windows port. As we progress we will add detailed problem reports and how we resolved those issues at individual pages.
20070724
works fine with GNU make and Intel Fortran compiler
1.0.4
port exists: http://gnuwin32.sourceforge.net/packages/bzip2.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves. a sage without bzip2 would be possible...; saved objects under unix/osx wouldn't load though.
XXXX
094b.p1
unclear how hard the port will be, but shouldn't be too hard.
XXXX
2.41.p12
MinGW port exists. Maintainer is receptive for build issues and usually fixes them quickly. maxima is often used under windows, so we should figure out their prefered lisp. We only use clisp for maxima.
conway_polynomials
0.2
platform independent, i.e. no known Windows specific issues trivial -- just a pickle
0.9.p5
Has Windows build support, provides binary packages
0.9.6.12
pure python, no portability issues, might needs some TLC for various config issues my impression from cython-devel is that there are already numerous windows users of cython
XXXX
dir
0.1
requires POSIX shell
XXXX
20080127.p0
Works fine on Cygwin, but needs a port to MSVC. Port is probably of medium complexity. A merge of fixes upstream is welcome, but maintainer no longer uses Windows. Maintainer = John Cremona = has never used Windows, as far as I know. Porting is reasonable.
elliptic_curves
0.1
elliptic curve database, so no porting issues
examples
2.10.2.alpha0
no compiled code, i.e. no problem
extcode
XXX
various code in interpreted languages, i.e. javascript, java, Magma, pari, singular, no porting issues
20070816.p0
part of scikits, should work with MSVC
1.06.p1
C99 based code, build system easy enough, Windows specific fixes welcome upstream. Hooked deeply into GMP. Main developer -- Bill Hart -- uses Windows all the time.
flintqs
20070817.p2
is obsolete, but should build fine once FLINT works, C99 mode required
2.1.6-20071129.p1
no Windows port, needs some specialized math functions, but should be a relatively easy port. Upstream will likely merge Windows patches worry?
2.3.5
unclear if it is even required on Windows.
20071120.p3
Use Intel's Fortran compiler. An alternative for 32 bit is g77.
4.4.10.p2
Depends on sbrk(), currently builds only via Cygwin. a cygwin build could be fine for us, since there is no binary linking between sage and gap, and almost certainly there never will be any.
XXXX
2.0.33.p5
port exists: http://gnuwin32.sourceforge.net/packages/gd.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves.
0.56.p4
should be pretty easy to do for MSVC Boothby told me this swig-generated "crap" will be removed from sage soon, he hopes.
0.3.p1
unclear, don't really see any problem easy, probably; it's just math
0.2.2.p2
unclear how hard the port will be, but shouldn't be too hard. we should upgrade to 0.2.3 first. Some more remarks: gfan requires argv[0] to switch to the right computation. I.e. during installation the following is executed: "ln -s gfan gfan_weightvector". This should be portable, but symlinks can be problematic on Windows.
3.2.6.p6
no port exists, C++ code uses templates and it migt. be a little tricky to get right. Upstream welcomes patches could be hard.
XXXX
2.2.1.p1
Shortly the spkgs for libgpg_error, libgcrypt and opencdk will disappear since gnutls now includes copies of them. gnutls has build support for 32 bit MSVC, the feasability of the 64 bit build needs to be investigated. Problems might crop up with inline assembly. maybe there is a native windows library that provides similar functionality. This is only needed so Twisted works with Python, and I'm sure that is already very well supported.
graphs
20070722
graph database, so no porting issues
1.0.1.p9
no port exists, but it should be pretty straight forward. this won't be hard, since iml is just clean C code, mostly concerned with mat
0.8.1.p1
should work fine with MSVC definitely will work fine.
ipython1
20070130
Windows port exists
XXXX
11.5.2.p1
pure java, no portability issues, large community of users on Windows
XXXX
20071123.p0
Works out of the box with GNU make.
20070107.p1
somewhat crafty C code, ugly hacks in the user interface, but should be portable to MSVC. Builds fine under Cygwin
1.4.0.p0
1.6.p0
1.2.22.p5
port exists: http://gnuwin32.sourceforge.net/packages/libpng.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves. In this case it seems likely that somebody else has done a proper Windows port. We might also be able to uses the system's library, but there might be issues with featurs, i.e. IE's libpng is supposed to be fairly bad. yep, something builtin to windows might be useful.
20070915.p5
this will be some heavy lifting, mostly due to some heavy templated code. Upstream is willing to merge and help out.
0.91.1.p3
should work with MSVC, more investigation is needed I'm sure this will work -- it is also part of what the enthought people distribute for windows.
5.13.0.p2
Should build fine with Clisp, Windows binary package exists.
0.9.5.p0
some C extensions, maybe some portability issues, might need some TLC for various config issues
moin
1.5.7.p2
python based, should work fine on Windows
1.3.4-cvs20071125.p5
depends on mpfr and gmp, pure C library. Port is simple and will probably be merged upstream
XXXX
ntl
5.4.1.p11
works fine with MSVC. Some functions like the time functions use old and crappy Win95+ interfaces. That can be easily fixed. It is very difficult to get fixes merged upstream, but the potential diff is rather small. The build requires Perl for a tuned build upstream merging probably isn't as hard as you think. The NTL author is a number theorist that many of "us", e.g,. John Cremona, know well.
opencdk
0.6.6
palp
1.1.p1
unclear how hard the port will be, but shouldn't be too hard.
pari
2.3.3
Some build support exists in tree, but it is currently broken. Support from the maintainers exists and they are willing to integrate fixes upstream. The main issue is to get the build system play nice for MinGW+MSVC.
pexpect
2.0.p1
This is the big, difficult one. pexpect uses pseudo ttys and a whole bunch of POSIX infrastructure. It is essential and central to Sage and no one has ported pexpect to Windows. While the API is very different it is still possible to map all functionality to native Windows API calls. But it will probably take a lot of energy to get it stable and clean. The ultimate goal would be to get this merged upstream since it would be quite a lot of work to go at this alone yes, this is the biggie. note that pexpect does sort of work under cygwin, which might be relevant. Also, instead of porting pexpect, it might be possible to simply do something completely different than accomplishes much the same thing. pexpect was the way to go with Python and Unix -- in windows perhaps there is a totally different approach to interprocess communication that would work better? It's possibly OK if this means rewriting SAGE_ROOT/devel/sage/sage/interfaces/ for this new approach. This definitely needs to be investigated. Some of the programs Sage interfaces with have native "client server" archicture, and that could perhaps be used instead. E.g., Maple and Mathematica do. Maxima almost certainly doesn't...
polybori
0.1-r7
no Windows port, could be tricky, but upstream is willing to cooperate. worry??
prereq
0.3
requires POSIX shell - small build system issues
pycrypto
2.0.1.p1
unclear how hard the port will be, but shouldn't be too hard. maybe trivial??
python
2.5.1.p13
excellent support for MSVC, 32 & 64 bit mode. yep, very very good support on windows
python_gnutls
1.1.4.p2
Should work, uses dlopen based mechanism. Is essential to the notebook, but can be dropped in favour of system's OpenSSL compatible library
quaddouble
2.2.p7
MSVC project exists, need to investigate 64 bit build
r
2.6.1.p14
Existing MinGW port, not too difficult to build. Port to MSVC desired. They don't already have a native MSVC port? Wow. That's amazing.
readline
5.2.p0
port exists: http://gnuwin32.sourceforge.net/packages/readline.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves.
rpy
1.0.1.p1
Support for MSVC in 32 bit mode with MSVC. No Cygwin support, but patch by Abshoff exists
rubiks
20070912.p1
no Windows port, but simple C/C++ code without any POSIX dependencies. Console applications easy?
sage_scripts
2.10.2.alpha0
requires POSIX shell
singular
3-0-4-1-20071209.p4
Cygwin only, but needs even work there to run properly (libSingular) Needs to be ported to MSVC, upstream very willing to help out, but lacks expertise. Various issues like memory managment (omalloc) need to be sovled (malloc fallback), but build system issues and stuff like signals make this a bigger job. I would assume this is one of the two heavy jobs together with pexpect. This is probably quite hard. And interesting. At least singular builds under cygwin, which is a good sign, I guess.
sqlite
3.5.3.p1
pure Windows port exists (see http://www.sqlite.org/download.html), but we need ???
symmetrica
2.0.p1
no Windows port yet, but macro heavy. worrisome.
sympow
1.018.1.p4
tricky code that needs the right FPU flags set. Otherwise no big hurdles to overcome
termcap
1.3.1
port exists: http://gnuwin32.sourceforge.net/packages/termcap.htm. Since that port uses MinGW we need to either use MinGW 64 bit or do an MSVC port ourselves.
twistedweb2
20070619.p0
python, is supported, relevant to notebook
twisted
2.5.0.p9
python, is supported, relevant to notebook
zlib
1.2.3.p3
port exists: http://gnuwin32.sourceforge.net/packages/zlib.htm Microsoft ships a copy under some name, so we might be able to "just" use the system one.
zodb3
3.7.0.p0
mostly python, unknown difficulty to port probably easy
Packages with upstream MSVC support
3.8.p11
Works find fine, Intel C for better performance preferred
6.1.3
no Windows port, but C, potentially issues with threading. Upstream ecm-6.2 has MSVC project by Brian Gladman - upgrading evm to the 6.2 release is #3237
1.10.p0
port exists: http://gnuwin32.sourceforge.net/packages/gsl.htm. Brian Gladman also maintains a native MSVC port, 32 & 64 bit.
20071224.p1
MSVC and SunForte port done by Martin Albrecht and in upstream. Upgrade ticket is #3204
2.3.1
pure C, Windows make file support welcome upstream, depends on gmp. MSVC project by Brian Gladman exists and is recommended by upstream
numpy
20080104-1.0.4.p2
support by enthought, builds out of the box with MSVC + ATLAS
scipy
20071020-0.6.p3
support by enthought, builds out of the box with MSVC + ATLAS
scipy_sandbox
20071020.p2
support by enthought, builds out of the box with MSVC + ATLAS
scons
0.97
works fine on Windows, python based.
tachyon
0.98beta.p4
Windows port exists, unsure about MSVC + threading.
weave
0.4.9
now part of scikits, works fine with MSVC
Pure Python Packages
networkx
0.36.p1
pure python, no portability issues
sympy
0.5.7
pure python, no portability issues.
Packages without code
doc
2.10.2.alpha0
no compiled code, so no portability issues.