Re: GSoC project: make the Sage build system more distribution friendly
On 10.04.2013 17:43, Felix Salfelder wrote:
> Hi Tobias
>
> On Tue, Apr 09, 2013 at 10:26:30AM +0200, Tobias Hansen wrote:
>> No, the toplevel install script must just be able to skip the
>> compilation of these spkg's. And tell the Sage library to use the
>> libraries that are available and were compiled independently.
>
> skipping compilation of spkgs (and the installation to
> /some/sage/prefix) and appending CPP/LD-FLAGS to environment variables
> during spkg builds seems feasible. this would require a configure
> script (or configure functionality)...
>
> picking the right flags for each spkg and/or fixing every single spkg to
> use them (correctly) is probably more work.
>
>>> it seems to be more work to fix sage ("the operating sytstem") than to
>>> properly ship sage ("the library") within an already working
>>> distribution (= properly checking for functionality/applied patches).
>>> these checks however are difficult to maintain, if upstream sage doesn't
>>> use them...
>
> i should write "sage the system", what i'm referring to is the tarball
> that contains the spkg's and the toplevel 'installer' makefile.
>
>> We want to do the changes to the build system in Sage, the two Sage
>> developers agreed to keep an eye on the progress so that we end up
>> with something they can accept in the end.
>
> 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.
>
>> As much tests as possible
>> would be great, but how would you check for applied patches in an
>> universal way?
>
> 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.
>
>> 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.
>
>> 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)
> - [..]
> - "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.
>
> depending on difficulties, i might be able do deal with both. but of
> course i want to clarify the details before i apply :)
>
> thanks
> felix
On 10.04.2013 17:52, Felix Salfelder wrote:
> On Tue, Apr 09, 2013 at 02:18:06PM +0200, Tobias Hansen wrote:
>> I get it, you are talking about dependencies between spkg's. Yes
>> that would require a central mechanism in Sage that provides all
>> spkgs with the information where the other stuff is, if we really
>> want the possibility to mix spkgs and system libraries.
>
> yes. something like that.
>
> but it seems to be a lot of uneccesary/duplicate work. it's probably
> more adequate to just skip spkgs and cross fingers -- for that matter.
>
> regards
> felix
Reply to: