[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly

Hi there.

On Thu, Apr 11, 2013 at 01:04:23AM +0200, Tobias Hansen wrote:
> Remember the git transition. spkg's will go away. There will be just one
> tarball containing everything in the future. The sources of other
> projects will be better separated, so it will be easy to get a Sage
> tarball without sources of other projects. Taking this into account, it
> probably makes sense to have only one Sage "Debian source package".

i have looked at the git repo at https://github.com/sagemath/sage.
as it seems, this repo contains the contents of (formerly?)
hg.sagemath.org/sage-main (and some more stuff) within src,
while the other spkgs have been replaced by a set of patches and rules
(couldnt find references to the original tarballs?), sorted into

in particular the contents of sage.spkg have been relocated and merged
with other stuff (ext, doc). i don't know why or how serious this is.

so current plans are to merge everything together (instead of for
example splitting up sage.spkg into c_lib and python-sage)?

> Switching to autotools is something we can't decide alone. What do Sage
> developers say? Do you mean with "Sage (the library)" all Sage
> components including notebook etc?

sage "the library" is the contents of sage.spkg. i.e. a shared library
(in c_lib) and a python module (in sage). (or *was* the contents of that

> It would still be nice if the top level script could be used by
> distributions. There are still several things to build and other things
> to do, if external dependencies are not built, and we should not
> implement all this in debian/rules. One could start with the option to
> build all or none of the dependencies and then maybe go further to allow
> more combinations. But I'm also not entirely sure if combining system
> and bundled dependencies is needed. Maybe an alternative build script
> for building with system libraries would be a better idea. Are there
> other opinions?

the top-level stuff in a way *is* a distribution. using it to build
debian packages makes things worse -- finally the purpose of
debian/rules will be mostly dissecting the components. look at singular
for a smaller example [1].

(i'm not saying, a top level configure script isnt useful for
local/manual installation).


[1] http://git.debian.org/?p=debian-science/packages/singular.git

Reply to: