Differences between revisions 1 and 42 (spanning 41 versions)
⇤ ← Revision 1 as of 2008-04-16 23:57:08 →
Size: 12287
Editor: MichaelAbshoff
Comment: copy of the "package analysis" section from the windows page
← Revision 42 as of 2010-08-18 15:54:41 → ⇥
Size: 18620
Editor: SazzadBinKamal
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
NOTE: [http://www.apcocoa.org/wiki/ApCoCoALib:CompilationInstructions Some other useful information] This page is part of the [[windows|Sage on Windows port]].
Line 3: Line 3:
 * dir-0.1 - requires POSIX shell
 * prereq-0.3 - requires POSIX shell - small build system issues
 * bzip2-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.]]		 == Package Analysis ==
Line 9: Line 5:
 * sage_scripts-2.10.2.alpha0 - requires POSIX shell
 * conway_polynomials-0.2 - platform independent, i.e. no known Windows specific issues
[[trivial -- just a pickle]]		 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.
Line 13: Line 7:
 * 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!]]		 == Build dependencies of Sage (port these first for a minimal Sage on Windows) ==
Line 17: Line 9:
 * 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.
 * 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.
 * 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.
 * 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.]]		  || Website || Win32 || Win64 || MSVC || Version || Comments ||
 || [[http://www.netlib.org/blas/ | blas]] || Y || [[http://www.canerten.com/compile-lapack-and-blas-as-dll-on-windows/ | Y]] || N/A || 20070724 || works fine with GNU make and Intel Fortran compiler ||
 || [[http://www.bzip.org/ | bzip2]] || Y || P || P || 1.0.4 || works fine with MSVC (32 bits at least) - required by python ||
 || [[http://users.tkk.fi/pat/cliquer.html | cliquer]] || N || N || N || XXXX || Docs say minor changes to source required for non-unix OSs ||
 || [[http://ecls.sourceforge.net/ | ecl]] ||Y || P ||Y || XXXX || See [[http://ecls.wikispaces.com/VCExpress | MSVC 2008 ]] and [[ http://www.microsoft.com/downloads/details.aspx?familyid=bd2a6171-e2d6-4230-b809-9a8d7548c1b6&displaylang=en | MSVC 2008 Redistributable Package(64) ]]||
 || [[http://wiki.sagemath.org/spkg/eclib | eclib]] || || || || 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.]] ||
 || [[http://www.flintlib.org/ | flint]] || || || || 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.]] ||
 || [[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?]] ||
 || [[http://www.g95.org/ | g95]] || || || || 20071120.p3 || Part of MinGW 32 and 64 - does not need to be ported to MSVC ||
 || [[http://www.libgd.org/Main_Page | gd]] || || || || 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. ||
 || [[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.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://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://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://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]] || Y || Y || Y || XXXX || [[http://gladman.plushost.co.uk/oldsite/computing/gmp4win.php | MPIR on Windows]] ||
|| [[http://www.shoup.net/ntl/ | 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.]] ||
 || openssl || || || || || required by Python - builds fine with MSVC (32 bits at least) ||
 || [[http://pari.math.u-bordeaux.fr/ | 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. ||
 || [[http://polybori.sourceforge.net/ | polybori]] || || || || 0.1-r7 || no Windows port, could be tricky, but upstream is willing to cooperate. [[worry??]] ||
 || [[http://pynac.sagemath.org/ | pynac]] || || || || XXXX || ||
 || [[http://www.python.org/ | python]] || || || || 2.5.1.p13 || excellent support for MSVC, 32 & 64 bit mode. [[yep, very very good support on windows]] ||
 || [[http://www.mathe2.uni-bayreuth.de/stoll/programs/index.html | ratpoints]] || || || || XXXX || ||
 || [[http://tiswww.case.edu/php/chet/readline/rltop.html | 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. ||
 || [[http://www.singular.uni-kl.de/ | 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.]] ||
 || [[http://www.sqlite.org/ | sqlite]] || || || || 3.5.3.p1 || pure Windows port exists (see http://www.sqlite.org/download.html), required by Python - builds fine with MSVC (32 bits at least) ||
 || [[http://www.algorithm.uni-bayreuth.de/en/research/SYMMETRICA/ | symmetrica]] || || || || 2.0.p1 || no Windows port yet, but macro heavy. [[worrisome.]] ||
 || tcl || || || || || Required by Python's IDLE - builds fine with MSVC (32 bits at least) ||
 || tk || || || || || Required by Python's IDLE - builds fine with MSVC (32 bits at least) ||
 || [[http://cims.nyu.edu/~harvey/code/zn_poly/ | znpoly]] || || || || XXXX || ||
Line 27: Line 43:
 * eclib-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.]]		 == Unknown dependencies of Sage (not listed on sage-on-gentoo list) ==
Line 31: Line 45:
 * graphs-20070722 - graph database, so no porting issues
 * elliptic_curves-0.1 - elliptic curve database, so no porting issues
 * extcode-XXX: various code in interpreted languages, i.e. javascript, java, Magma, pari,
  . singular, no porting issues
 * flint-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.]]		  || Website || Win32 || Win64 || MSVC || Version || Comments ||
 || [[http://www.boost.org/ | boost]] || Y || P || P || XXXX || ||
 || cephes || N || N || N || || Last updated circa 1994, small library, but uses long doubles - only used in the Cygwin port so far (and FreeBSD in future) ||
 || [[http://docutils.sourceforge.net/ | docutils]] || || || || XXXX || ||
 || [[http://www.netlib.org/f2c/ | f2c]] || || || || 20070816.p0 || part of scikits, should work with MSVC ||
 || [[http://www.freetype.org/ | freetype]] || || || || 2.3.5 || unclear if it is even required on Windows. ||
 || [[http://www.hpl.hp.com/personal/Hans_Boehm/gc/ | gc]] || || || || 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.]] ||
 || [[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://mercurial.selenic.com/wiki/ | mercurial]] || || || || 0.9.5.p0 || some C extensions, maybe some portability issues, might need some TLC for various config issues ||
 || [[http://www.gnu.org/software/gnutls/ | opencdk]] || || || || 0.6.6 || ||
 || [[http://www.pythonware.com/library/index.htm | pil]] || || || || XXXX || ||
 || sage_scripts || || || || 2.10.2.alpha0 || requires POSIX shell ||
 || [[http://pypi.python.org/pypi/setuptools/ | setuptools]] || || || || XXXX || ||
 || [[http://www.sqlalchemy.org/ | sqlalchemy]] || || || || XXXX || ||
 || [[http://www.catb.org/~esr/terminfo/ | 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. ||
 
== Runtime dependencies of Sage (these are probably only needed at runtime for specific functionality) ==
Line 39: Line 65:
 * 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.
 * sqlite-3.5.3.p1 - pure Windows port exists (see http://www.sqlite.org/download.html), but
  . we need ???
 * libgpg_error-1.6.p0, libgcrypt-1.4.0.p0, opencdk-0.6.6, 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.]]		  || Website || Win32 || Win64 || MSVC || Version || Comments ||
 || [[http://www.ifor.math.ethz.ch/~fukuda/cdd_home/ | cddlib]] || N || N || N || 094b.p1 || unclear how hard the port will be, but shouldn't be too hard. ||
 || cu2 || || || || || ||
 || cubex || || || || || ||
 || [[http://abel.ee.ucla.edu/cvxopt/ | cvxopt]] || Y || N || N || 0.9.p5 || Has Windows build support, provides binary packages ||
 || dikcube || || || || || ||
 || 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 ||
 || flintqs || || || || 20070817.p2 || is obsolete, but should build fine once FLINT works, C99 mode required ||
 || [[http://www-groups.dcs.st-and.ac.uk/~gap/ | gap]] || || || || 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.]] ||
 || gap-guava || || || || || ||
 || [[http://newcenturycomputers.net/projects/gdmodule.html | gdmodule]] || || || || 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.]] ||
 || [[http://www.math.u-bordeaux.fr/~liu/G2R/ | genus2reduction]] || || || || 0.3.p1 || unclear, don't really see any problem [[easy, probably; it's just math]] ||
 || [[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://ipython.scipy.org/moin/ | ipython]] || || || || 0.8.1.p1 || should work fine with MSVC [[definitely will work fine.]] ||
 || [[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://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. ||
 || mcube || || || || || ||
 || sage-notebook || || || || || ||
 || [[http://www.math.ucf.edu/~reid/Rubik/optimal_solver.html | optimalrubik]] || || || || 20070912.p1 || no Windows port, but simple C/C++ code without any POSIX dependencies. Console applications [[easy?]] ||
 || [[http://hep.itp.tuwien.ac.at/~kreuzer/CY/CYpalp.html | palp]] || || || || 1.1.p1 || unclear how hard the port will be, but shouldn't be too hard. ||
 || [[http://www.noah.org/wiki/Pexpect | pexpect]] || || || || 2.0.p1 || Difficult. 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. Instead of porting pexpect, it might be possible to do something different that accomplishes the same thing. pexpect was the way to go with Python and Unix. It's possibly OK if this means rewriting SAGE_ROOT/devel/sage/sage/interfaces/ for this new approach. 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... ||
 || [[http://www.amk.ca/python/code/crypto | pycrypto]] || || || || 2.0.1.p1 || unclear how hard the port will be, but shouldn't be too hard. [[maybe trivial??]] ||
 || 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 ||
 || [[http://www.r-project.org/ | 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.]] ||
 || sage-doc || || || || || ||
 || sage-latex || || || || || ||
 || [[http://rpy.sourceforge.net/ rpy]] || || || || 1.0.1.p1 || Support for MSVC in 32 bit mode with MSVC. No Cygwin support, but patch by Abshoff exists ||
 || [[http://sphinx.pocoo.org/ | sphinx]] || || || || XXXX || ||
 || sympow || || || || 1.018.1.p4 || tricky code that needs the right FPU flags set. Otherwise no big hurdles to overcome ||
Line 47: Line 99:
 * 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.]]		 == Do not correspond to Sage spkgs (elsewhere or no longer used in Sage?) ==
Line 51: Line 101:
 * python-2.5.1.p13: excellent support for MSVC, 32 & 64 bit mode.
[[yep, very very good support on windows]]		  || Website || Win32 || Win64 || MSVC || Version || Comments ||
 || [[http://www.warwick.ac.uk/staff/J.E.Cremona/mwrank/index.html | mwrank]] || || || || XXXX || Is this now eclib in Sage?? ||
Line 54: Line 104:
 * freetype-2.3.5: unclear if it is even required on Windows.
 * gd-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.
 * gdmodule-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.]]		 == No longer listed on sagemath.org and not included as spkgs ==
Line 60: Line 106:
 * fortran-20071120.p3: Use Intel's Fortran compiler. An alternative for 32 bit is g77.
 * lapack-20071123.p0: Works out of the box with GNU make.
 * atlas-3.8.p11: Works find [[fine]], Intel C for better performance preferred
 * gsl-1.10.p0: port exists: http://gnuwin32.sourceforge.net/packages/gsl.htm
  . Brian Gladman also maintains a native MSVC port, 32 & 64 bit.
 * 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]]		  || Website || Win32 || Win64 || MSVC || Version || Comments ||
 || dir || || || || 0.1 || requires POSIX shell ||
 || [[http://www.openopt.org/Welcome | openopt]] || || || || XXXX || ||
 || prereq || || || || 0.3 || requires POSIX shell - small build system issues ||
Line 68: Line 111:
 * ipython-0.8.1.p1: should work fine with MSVC
[[*definitely* will work fine.]]		 == Packages with upstream MSVC support ==
Line 71: Line 113:
 * givaro-3.2.6.p6: no port exists, C++ code uses templates and it might
  . be a little tricky to get right. Upstream welcomes patches
[[could be hard.]]		  || Website || Win32 || Win64 || MSVC || Version || Comments ||
 || [[http://math-atlas.sourceforge.net/ | atlas]] || || || || 3.8.p11 || Works find [[fine]], Intel C for better performance preferred ||
 || [[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 ||
 || [[http://numpy.scipy.org/ | numpy]] || || || || 20080104-1.0.4.p2 || support by enthought, builds out of the box with MSVC + ATLAS ||
 || [[http://www.scipy.org/ | 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 ||
 || [[http://www.scons.org/ | scons]] || || || || 0.97 || works fine on Windows, python based. ||
 || [[http://jedi.ks.uiuc.edu/~johns/raytracer/ | tachyon]] || || || || 0.98beta.p4 || Windows port exists, unsure about MSVC + threading. ||
 || [[http://www.scipy.org/Weave | weave]] || || || || 0.4.9 || now part of scikits, works fine with MSVC ||
 || [[http://www.zlib.net/ | 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. ||
 || [[http://www.zodb.org/ | zodb]] || || || || 3.7.0.p0 || mostly python, unknown difficulty to port [[probably easy]] ||
Line 75: Line 128:
 * f2c-20070816.p0: part od [[of]] scikits, should work with MSVC
 * blas-20070724: works fine with GNU make and Intel Fortran compiler
 * numpy-20080104-1.0.4.p2: support by enthought, builds out of the box
  . with MSVC + ATLAS
 * 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.]]		 == Pure Python Packages ==
 || Website || Win32 || Win64 || MSVC || Version || Comments ||
 || [[http://www.cython.org/ | cython]] || N/A || N/A || N/A || 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]] ||
 || moin || || || || 1.5.7.p2 || python based, should work fine on Windows ||
 || [[http://code.google.com/p/mpmath/ | mpmath]] || || || || XXXX || ||
 || [[http://networkx.lanl.gov/ | networkx]] || || || || 0.36.p1 || pure python, no portability issues ||
 || [[http://code.google.com/p/sympy/ | sympy]] || || || || 0.5.7 || pure python, no portability issues. ||
 || [[http://twistedmatrix.com/trac/ | twisted]] || || || || 2.5.0.p9 || python, is supported, relevant to notebook ||
Line 82: Line 137:
 * mercurial-0.9.5.p0 - pure python, no portability issues, might need some
  . TLC for various config issues
[[will be easy]]

 * mpfr-2.3.1: pure C, Windows make file support welcome upstream, depends
  . on gmp.
 * 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...]]

 * mpfi-1.3.4-cvs20071125.p5: depends on mpfr and gmp, pure C library.
  . Port is simple and will probably be merged upstream
 * pycrypto-2.0.1.p1: unclear how hard the port will be, but shouldn't be
  . too hard.
[[maybe trivial??]]

 * cython-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]]

 * sympy-0.5.7: pure python, no portability issues.
 * zodb3-3.7.0.p0: mostly python, unknown difficulty to port
[[probably easy]]

 * networkx-0.36.p1: pure python, no portability issues
 * quaddouble-2.2.p7: MSVC project exists, need to investigate 64 bit build
 * 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
 * twistedweb2-20070619.p0 - python, is supported, relevant to notebook
 * twisted-2.5.0.p9 - python, is supported, relevant to notebook
 * 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.]]

 * scons-0.97: works fine on Windows, python based.
 * symmetrica-2.0.p1: no Windows port yet, but macro heavy.
[[worrisome.]]

 * 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?]]

 * polybori-0.1-r7: no Windows port, could be tricky, but upstream is
  . willing to cooperate.
[[worry??]]

 * rpy-1.0.1.p1: Support for MSVC in 32 bit mode with MSVC. No
  . Cygwin support, but patch by Abshoff exists
 * 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.]]

 * rubiks-20070912.p1: no Windows port, but simple C/C++ code without
  . any POSIX dependencies. Console applications
[[easy?]]

 * libm4ri-20071224.p1: no Windows port, maintainer will accept
  . Windows port
 * ecm-6.1.3: no Windows port, but C, potentially issues with
  . threading
[[worrisome.]]

 * examples-2.10.2.alpha0: no compiled code, i.e. no problem
 * clisp-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.]]

 * maxima-5.13.0.p2: Should build fine with Clisp, Windows binary
  . package exists.
 * genus2reduction-0.3.p1: unclear, don't really see any problem
[[easy, probably; it's just math]]

 * lcalc-20070107.p1: somewhat crafty C code, ugly hacks in the
  . user interface, but should be portable to MSVC. Builds fine under Cygwin
 * sympow-1.018.1.p4: tricky code that needs the right FPU flags
  . set. Otherwise no big hurdles to overcome
 * cddlib-094b.p1: unclear how hard the port will be, but shouldn't be
  . too hard.
 * 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.
 * weave-0.4.9: now part of scikits, works fine with MSVC
 * flintqs-20070817.p2: is obsolete, but should build fine once FLINT
  . works, C99 mode required
 * palp-1.1.p1: unclear how hard the port will be, but shouldn't be
  . too hard.
 * moin-1.5.7.p2: python based, should work fine on Windows
 * ipython1-20070130: Windows port exists
 * 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
 * cvxopt-0.9.p5: Has Windows build support, provides binary packages
 * jmol-11.5.2.p1: pure java, no portability issues, large community
  . of users on Windows
 * tachyon-0.98beta.p4: Windows port exists, unsure about MSVC +
  . threading.
 * linbox-20070915.p5: this will be some heavy lifting, mostly due
  . to some heavy templated code. Upstream is willing to merge and help out.
 * gap-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.]]

 * doc-2.10.2.alpha0: no compiled code, so no portability issues.		 == Packages without code ==
 || Website || Win32 || Win64 || MSVC || Version || Comments ||
 || conway_polynomials || N/A || N/A || N/A || 0.2 || platform independent, i.e. no known Windows specific issues [[trivial -- just a pickle]] ||
 || doc || || || || 2.10.2.alpha0 || no compiled code, so no portability issues. ||
 || elliptic_curves || || || || 0.1 || elliptic curve database, so no porting issues ||
 || graphs || || || || 20070722 || graph database, so no porting issues ||
 || polytopes || || || || || ||

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.

Build dependencies of Sage (port these first for a minimal Sage on Windows)

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.

Unknown dependencies of Sage (not listed on sage-on-gentoo list)

Runtime dependencies of Sage (these are probably only needed at runtime for specific functionality)

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    cddlib

    N

    N

    N

    094b.p1

    unclear how hard the port will be, but shouldn't be too hard.

    cu2

    cubex

    cvxopt

    Y

    N

    N

    0.9.p5

    Has Windows build support, provides binary packages

    dikcube

    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

    flintqs

    20070817.p2

    is obsolete, but should build fine once FLINT works, C99 mode required

    gap

    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.

    gap-guava

    gdmodule

    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.

    genus2reduction

    0.3.p1

    unclear, don't really see any problem easy, probably; it's just math

    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.

    ipython

    0.8.1.p1

    should work fine with MSVC definitely will work fine.

    jinja

    XXXX

    jmol

    11.5.2.p1

    pure java, no portability issues, large community of users on Windows

    jsmath

    XXXX

    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.

    mcube

    sage-notebook

    optimalrubik

    20070912.p1

    no Windows port, but simple C/C++ code without any POSIX dependencies. Console applications easy?

    palp

    1.1.p1

    unclear how hard the port will be, but shouldn't be too hard.

    pexpect

    2.0.p1

    Difficult. 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. Instead of porting pexpect, it might be possible to do something different that accomplishes the same thing. pexpect was the way to go with Python and Unix. It's possibly OK if this means rewriting SAGE_ROOT/devel/sage/sage/interfaces/ for this new approach. 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...

    pycrypto

    2.0.1.p1

    unclear how hard the port will be, but shouldn't be too hard. maybe trivial??

    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

    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.

    sage-doc

    sage-latex

    http://rpy.sourceforge.net/ rpy

    1.0.1.p1

    Support for MSVC in 32 bit mode with MSVC. No Cygwin support, but patch by Abshoff exists

    sphinx

    XXXX

    sympow

    1.018.1.p4

    tricky code that needs the right FPU flags set. Otherwise no big hurdles to overcome

Do not correspond to Sage spkgs (elsewhere or no longer used in Sage?)

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    mwrank

    XXXX

    Is this now eclib in Sage??

No longer listed on sagemath.org and not included as spkgs

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    dir

    0.1

    requires POSIX shell

    openopt

    XXXX

    prereq

    0.3

    requires POSIX shell - small build system issues

Packages with upstream MSVC support

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    atlas

    3.8.p11

    Works find fine, Intel C for better performance preferred

    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

    gsl

    1.10.p0

    port exists: http://gnuwin32.sourceforge.net/packages/gsl.htm. Brian Gladman also maintains a native MSVC port, 32 & 64 bit.

    m4ri

    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

    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

    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.

    zodb

    3.7.0.p0

    mostly python, unknown difficulty to port probably easy

Pure Python Packages

Packages without code

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    conway_polynomials

    N/A

    N/A

    N/A

    0.2

    platform independent, i.e. no known Windows specific issues trivial -- just a pickle

    doc

    2.10.2.alpha0

    no compiled code, so no portability issues.

    elliptic_curves

    0.1

    elliptic curve database, so no porting issues

    graphs

    20070722

    graph database, so no porting issues

    polytopes