Re: [sage-devel] Re: GSoC project: make the Sage build system more distribution friendly
Hi,
I'll give some answers from my point of view as one of the lead of sage-on-
gentoo https://github.com/cschwan/sage-on-gentoo. Some of the problems
discussed we encountered and have an opinion on. Whether some of the things
we do or have done are applicable to Debian is best answered by Debian people
themselves.
On Thu, 11 Apr 2013 01:04:23 Tobias Hansen wrote:
> Am 10.04.2013 17:43, schrieb Felix Salfelder:
> > several parts of fixing/changing/improving the sage (the system) build
> > system is unrelated to distributing sage "the library". so "changes to
> > the build system in Sage" is somewhat vague.
> >
> > i think a build system for the sage library should at least check
> > availibility (especially optional dependencies). more checks for
> > versions/header functionality/existing symbols are implemented within
> > autotools. the universal way would be maintaining these checks (which
>
> is unrealistic). catching common caveats should be possible.
>
>
> I mostly thought about the build system of the Sage system until now and
> didn't think about the build process of the library. Since availability
> of dependencies is ensured by the Sage system, the build process of the
> Sage library doesn't check for dependencies, right? Your idea is to add
> dependency checks to the library build, and that may be a good idea, but
> one could also consider to let the top level build scripts keep the job
> of handling the dependencies and do the checks there. I'm not saying
> that this would be better, just that this was my idea until now.
>
Indeed sage is built from a top makefile and dependencies between the various
spkg and sage itself are defined in spkg/standard/deps. This is used for
building standard sage. For distribution purpose it is useful to separate
these in two class, build time dependencies and pure run-time dependencies.
For example scipy is not required at build time but will be required at run
time.
Sage also has some optional dependencies, some which are built time are
usually checked in module_list.py (at the end). The sage package management
system is invoked to check whether the package is installed.
Run time optional dependencies are either checked through the sage package
management system or presence of key files.
>From the point of view of a linux distribution, my opinion is that the package
management system should be extracted. If it comes from your distro the
packages and upgrades are handled by the distro mechanism, except for stuff
that (can) live in the final user home directory.
> >> Every distribution has its own way to organize
> >> patches. I think Sage already has a good test coverage and a Debian
> >> package should of course run all the tests during build.
> >
> > iirc the tests are contained within sage.spkg (where the library is), so
> > that should be possible. other tests may come within other spkgs.
>
> 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".
>
Yes and no, see below.
> >> It seems to me that you understood that Sage should build all spkg's
> >> in any case and just install them somewhere else. I think that means
> >> the step you call "fix Sage the operating system" is not needed
> >> right? Now that I have clarified this, any new thoughts?
> >
> > for debian or other distributions, i dont see the need for any changes
> > to sage (the system). making sagelib distributable doesn't help skipping
> > spkgs. so there are still two subprojects:
> >
> > - improve sage (the library) distributability
> >
> > - enhance setup.py (better switch to autotools)
> > - get libcsage.deb and python-sage.deb packages
> > - run the unit tests from debian/rules
> > - (also pack other stuff)
> > - pave the way for local spkgs (e.g. installed to ~/.sage/local)
> > - [..]
>
> 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 itself has currently several components that are shipped separately and
at least one that should be split:
sage_root: which has all the elements of the basic build system and
traditionally the scripts to start sage.
sage_scripts: a collection of various scripts and command to run and tests
sage.
extcode: various bits and pieces accumulated over time. I understand it will
disappear in the git migration being integrated elsewhere.
sage: the python extension itself plus the c library. The c library is the
element we think should be split (and we do in sage-on-gentoo).
Whether to keep this structure in Debian or after the git transition is not
for me to answer. But I strongly believe the c library needs to be available
separately from the python library. The c library is built with scons which
has its detractors (that includes me) but is seriously too small to justify
autotooling in my opinion.
> > - "fix sage the system"
> >
> > - implement/incorporate top level configure script
> > - figure out flags, pass down to spkg-compilation
> > - build sage the upstream way skipping some spkgs
> > - [..]
> >
> > in fact, the second is not needed, neither for me, nor for the debian
> > package. the project description implies something different, which is
> > confusing.
>
> 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 questions has arisen several time in the past 5 years but in spite of some
suggestions on how to achieve this, no one has done the work. You are welcome
to have a go at it. If you start it you may get a surprising number of
helpers. I think most of the inertia is in starting it.
Francois
Reply to: