Re: GSoC project: make the Sage build system more distribution friendly
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".
>> 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
Reply to: