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

On Wed, Apr 10, 2013 at 4:04 PM, Tobias Hansen <thansen@debian.org> 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.

>> 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".

spkgs won't fully go away -- with the initial transition we are simply emulating the current spkg model. That said, there has been some work in transitioning to the ebuild format to use portage as a package manager -- but from what I understand, this is still a ways off.

One thing to note with the git transition is that I made an effort to (mostly) separate the build system from the sage library (by this I mean the core components of sage: the python library, csage, documentation, scripts, ...). So hopefully this will help in determining what is needed in packaging sage.

For those so inclined to browse the current status of the git transition, the repository is at https://github.com/sagemath/sage.

>> 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?

> - "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?

Cheers,
Tobias

--
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+unsubscribe@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