When you say "write/exchange the build systems for the core parts (c_lib,
python-sage, extcode...)" what exactly is your goal?
I don't think it makes much sense completely rewriting the setup.py/modules,
especially in Makefile (as it sounds like you might have been thinking).
If you are looking for making an autotools based build system (here
assuming part of your goal for (1) is to make a single configure for all of
"sage as a program") then I would suggest just calling `python setup.py
build` and `python setup.py install` in the appropriate places.
On Sun, Apr 21, 2013 at 3:17 AM, Felix Salfelder <fe...@salfelder.org>wrote:
> On Thu, Mar 28, 2013 at 01:14:10AM +0100, Tobias Hansen wrote:
> > Two people from Sage, Jeroen Demeyer and John Palmieri, volunteered to
> > cover the Sage side of mentoring the project. Julien Puydt, who already
> > put a lot of work into packaging Sage dependencies for Debian, is also
> > on board. All we need now is a student.
>
> Hi there.
>
> I'd like to draft a project proposal corresponding to this idea [1]
> following the proposal template. Comments are welcome.
>
> === Title, Project Synopsis
> "Get Sage ready for Linux distributions"
>
> Sage is currently shipped as a software distribution that, next to
> genuine code, includes all dependencies as foreign packages.
> Moreover, the core library and python modules cannot be compiled in a
> straightforward way, as most linux distributions expect. Aim of this
> project is to detach the build process of sage ("the software") from
> sage ("the distribution"). The goal is a build system that works within
> the context of sage as well as for any gnu/linux distribution that ships
> the dependencies for sage.
>
> === Personal involvement/relationship
> To me, a Debian user, who likes maths (and doesn't like big Ms), this
> project fills an obvious gap. I have already worked on packaging sage
> dependencies for debian occasionally. There, I have learned some of the
> basics of packaging and software distribution. I found out that a
> package for sage cannot be done overnight...
>
> === Details
> Switching the build system of the core parts to autotools allows
> implementing a standard interface to build and install the software.
> Such a build system includes a mechanism to figure out the
> availibility/names/locations of tools/headers/libraries and adapts the
> build/install process accordingly.
>
> An autotools build system can be used easily by package generation
> scripts such as debhelper (creating Debian packages) and can be called
> from within sage ("the distribution"). The difference between these uses
> consists in passing different flags to the corresponding "configure"
> script.
>
> This sums up to three tasks
> 1 write/exchange the build systems for the core parts (c_lib,
> python-sage, extcode...).
> 2 modify sage ("the distribution") to use the new build systems instead
> of running 'setup.py'.
> 3 build stand-alone sage, draft debian packages, figure out dependencies
>
> which split up into [optional in brackets]
> 1 - carefully read setup.py (within the sage-git-transition repo)
> - implement checks for headers and libraries
> - implement configure switches where needed
> - find convenient/flexible way of writing down targets (Makefile.am
> layout)
> - convert module_list.py to Makefile.ams. automatically if possible.
> - figure out run-time-paths, patch where needed.
> 2 - compile sage ("the distribution")
> - figure out configure environment/switches needed within sage
> - (add additional options if/where needed)
> - somehow handle sage-scripts ("bin") and doc
> - run test suite...
> - [discuss how "toplevel configure" can be done]
> 3 - install dependencies
> - compile everything
> - discuss appropriate number of source packages
> - write control files etc.
> - prepare sage-scripts for system wide installation
> - run tests on debian [gentoo]
> - [package sage-doc]
>
> === Schedule
> During the GSoC period I have no university work obligations as I'm on
> parental leave.
>
> - I won't be at home May 3 till May 19. still trying to stay connected
> - From July 27 to Aug 4 I will be most likely unavailable
> - i'll be away another two weeks in summer (Jul/Aug), not fixed yet.
>
> === Risk Management
> The tasks list includes the inevitable parts and doesn't promise an
> instant switch to a different build system. This would be the ultimate
> goal for the sage project, beyond the scope of a GSoC project.
>
> There is hardly any risk, that work done within this project turns out
> to be useless. If difficulties occur, the modularity of the approach
> allows postponing problems in 1 while still continuing to work on 2 and
> 3. On the other hand, if time permits, I can work out the optional
> parts.
>
> regards
> felix
>
> [1]
> https://docs.google.com/document/d/1ipzvwbhfujaubDe0QVO-V9JmmRcLZvitaeXh4r2WNqA/pub#h.pty9ayy9wo8
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
Andrew
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.com.
Visit this group at http://groups.google.com/group/sage-devel?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
