On Tue, Apr 23, 2013 at 06:08:54PM -0300, Paulo César Pereira de Andrade wrote:
> I will make a few comments, attempting to be as constructive
> as possible :-)
Hi Paolo, hi list.
Thanks for going through all this. i'll consider your comments as far
as the scope of this project allows.
> The biggest problem is compatibility of version of the components.
> Sagemath works in its current setup due to bundling most components,
> so that it can be built on a 3 year old distribution as well as on a
> bleeding edge one.
... compiling all of its dependencies. part of my proposal is
to make it possible to just install sage ("the distribution") skipping
everything but the core modules and the notebook.
depending on the changes needed within the foreign packages (read
"spkg-install or successor"), this could quickly evolve to --(un)skip
options for all modules. so even on a 3 year old distribution sage ("the
distribution") may run with less compilation effort.
there is hope that, once people start using sage ("the distribution")
using their own versions of dependencies, sage will start to
accept/incorporate small patches working around the smaller issues
(controlled by ./configure).
> [..]
> Some more strict rules on spkg would
> make it actually easier to get sagemath integrated in distributions,
> example:
> o avoid carrying patches that upstream does not accept,
> or were never submitted upstream.
that has reduced significantly in the past. almost all sage dependencies
are avaible in debian right now (and sage-ready). this is mostly due to
Julien Puydt. submitting upstream is his favourite way.
> o avoid creating spkgs of software that does not have a home
> page, or that is a snapshot of something without any ETA to
> be released, and not available anywhere for download.
as soon as what i call "embedded modules" works for sage ("the
distribution"), adding more code/modules to the git repo will be
painless. it will not complicate or disrupt the build system. (i'm
still arguing that this is the only way to go).
> One example is scons usage, that I patch to generate a more
> standard library:
> [..]
nobody should have to patch build systems. if (because) scons doesnt
work, i'll replace it. patches that work under any conditions can be
easily accepted upstream.
> > 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, sage-scripts, extcode, ...).
>
> c_lib should be split out of the sage-$version directory. This way,
> IMO, there is not much of a need to change how the core python
> modules are built. Well, I would be happy enough to not need to
> add this pseudo patch:
c_lib is currently in <git-repo>/src and will/should be treated as a
module. there will be no sage-$version package anylonger.
debian will distribute the contents of <git-repo>/src (as a source
package). you may choose to pick the subdirectories seperately.
> +if os.environ.has_key('DESTDIR'):
> + DESTDIR = os.environ['DESTDIR']
> +else:
> + DESTDIR = ''
> [...]
> - pyx_inst_file = '%s/%s'%(SITE_PACKAGES, f)
> + pyx_inst_file = '%s%s/%s'%(DESTDIR, SITE_PACKAGES, f)
>
> to setup.py.
i will most likely replace setup.py by a template, filled from
./configure. (or replaced completely by Makefile.am's, depending what
works better). in any case, all build systems i'm going to write will
implement
- --prefix option for ./configure
- make install target honouring DESTDIR (the way you propose or another)
in particular, all build systems will be interfaced by configure/make,
which will then be consistent throughout all core modules, and finally
be ready to use for sage ("the distribution") without further glue code.
> > 1 - carefully read setup.py (within the sage-git-transition repo)
> > - implement checks for headers and libraries
> > - implement configure switches where needed
>
> I see this as a great improvement, but also consider adding checks
> in the more pythonic way to the "current" build system.
please enlighten me about what the pythonic way is. does it support a
configure/make interface?
> > 3 - install dependencies on a debian machine
> > - compile everything
> > - prepare sage-scripts for system wide installation
>
> My current approach is to add the location of sage scripts
> to $PATH, and besides some symbolic links from system
> directories to SAGE_ROOT, in most sage scripts I just
> remove in a patch the hardcoded $SAGE_LOCAL/bin
> prefix to binaries.
$PATH should be default in non-sage-("the distribution") cases. other
paths should be handled by proper -I and -L etc. *FLAGS. symlinks are bad.
> > 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.
>
> While it is not trivial, it has been done before to Debian as you
> already know, http://wiki.sagemath.org/devel/DebianSage
yes, but is abuses the makefile intended for sage ("the distribution")
and patches the hell out of most files. none of this is portable to
newer versions. this (and missing dependencies) is why nobody was able
to catch up.
> So, one of the major issues should be continued maintenance.
i agree.
> It is very important to have "core" sagemath developers as distro
> packagers;
i'm not so sure. once the structure and purpose of the build process is
clear, anyone should be able to add/remove/change parts.
> personally, I would be very happy in mentoring and
> giving comantainership of sagemath for Fedora, and for Debian
> it should not be much different.
that's great.
regards
felix
--
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.
