Differences between revisions 26 and 27
⇤ ← Revision 26 as of 2010-08-16 20:43:25 →
Size: 17247
Editor: BillHart
Comment:
← Revision 27 as of 2010-08-17 00:05:21 → ⇥
Size: 17601
Editor: BillHart
Comment: pulled out runtime deps into own section
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
== Build dependencies of Sage (port these first for a minimal Sage on Windows) ==
Line 11: Line 13:
 || [[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. ||
Line 14: Line 15:
 || conway_polynomials || N/A || N/A || N/A || 0.2 || platform independent, i.e. no known Windows specific issues [[trivial -- just a pickle]] ||
 || [[http://abel.ee.ucla.edu/cvxopt/ | cvxopt]] || Y || N || N || 0.9.p5 || Has Windows build support, provides binary packages ||
Line 21: Line 20:
 || 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 ||
Line 26: Line 22:
 || flintqs || || || || 20070817.p2 || is obsolete, but should build fine once FLINT works, C99 mode required ||
Line 30: Line 25:
 || [[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.]] ||
Line 33: Line 27:
 || [[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. ||
Line 39: Line 30:
 || graphs || || || || 20070722 || graph database, so no porting issues ||
Line 41: Line 31:
 || [[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 || ||
Line 51: Line 39:
 || [[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. ||
Line 61: Line 47:
 || [[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. ||
Line 64: Line 48:
 || [[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... ||
Line 68: Line 51:
 || [[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??]] ||
Line 70: Line 52:
 || 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 ||
Line 72: Line 53:
 || [[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.]] ||
Line 75: Line 55:
 || [[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 ||
Line 79: Line 58:
 || [[http://sphinx.pocoo.org/ | sphinx]] || || || || XXXX || ||
Line 82: Line 60:
 || [[http://www.sqlite.org/ | ]] || || || || XXXX || ||
Line 84: Line 61:
 || [[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. ||
 || [[http://twistedmatrix.com/trac/ | twisted]] || || || || 2.5.0.p9 || python, is supported, relevant to notebook ||
 || [[http://cims.nyu.edu/~harvey/code/zn_poly/ | znpoly]] || || || || XXXX || ||

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

 || [[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 || || || || || ||
 || dikcube || || || || || ||
 || [[http://abel.ee.ucla.edu/cvxopt/ | cvxopt]] || Y || N || N || 0.9.p5 || Has Windows build support, provides binary packages ||
 || flintqs || || || || 20070817.p2 || is obsolete, but should build fine once FLINT works, C99 mode required ||
 || 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 ||
 || [[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://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 || ||
Line 85: Line 97:
 || 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. ||
 || twisted || || || || 2.5.0.p9 || python, is supported, relevant to notebook ||
 || [[http://cims.nyu.edu/~harvey/code/zn_poly/ | znpoly]] || || || || XXXX || ||
Line 102: Line 111:
 || [[http://www.catb.org/~esr/terminfo/ | termcap]] || || || || XXXX || ||
 || [[http://twistedmatrix.com/trac/ | twisted]] || || || || XXXX || ||
Line 116: Line 123:
 || conway_polynomials || N/A || N/A || N/A || 0.2 || platform independent, i.e. no known Windows specific issues [[trivial -- just a pickle]] ||
Line 117: Line 125:
 || 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)

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

  • cddlib

    N

    N

    N

    094b.p1

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

    cu2

    cubex

    dikcube

    cvxopt

    Y

    N

    N

    0.9.p5

    Has Windows build support, provides binary packages

    flintqs

    20070817.p2

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

    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

    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

    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

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

  • Website

    Win32

    Win64

    MSVC

    Version

    Comments

    mpmath

    XXXX

    networkx

    0.36.p1

    pure python, no portability issues

    sympy

    0.5.7

    pure python, 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