On Wed, 16 Jan 2013 08:43:15 +0100 Julien Puydt <julien.pu...@laposte.net> wrote:
> Le 15/01/2013 23:28, Volker Braun a écrit : > > The specialist mathematical libraries, by contrast, don't get much > > exposure. And even if somebody packaged them then generally in > > useless form. E.g. Fedora ships symmetrica, but its useless since > > it is not compiled with -DFAST. Which nobody knows what it does > > except that, otherwise, you'll get segfaults. So for all practical > > purposes we have to build private versions of some libraries. And > > since they haven't been written by software engineers the > > individual build systems are generally a mess, so you can mostly > > forget about configure/make/make install. So essentially we'll have > > to use the current system of shell scripts to build the beast, > > there often isn't much logic that can be shared between them. > > (1) Any patch to upstream should be forwarded upstream. > > (2) If upstream doesn't have a good build system, provide one, and > don't forget (1). I agree with Julien. The symmetrica example shows that everyone can benefit from the testing and packaging work done by the Sage team. I don't see how treating mathematical software as second class can be justified because most of it does not have a proper build system. We benefit from the code released by the author, we should at least contribute our fixes back and publicize them instead of maintaining our own copy. Take eclib as an example. IIRC, it was John Cremona's private code until William convinced him to release the code under GPL, and included it in Sage. In time it got progressively better, for example an autotools based build system and using FLINT for some functionality (only in a development release I suppose). These improvements are available for anyone else to use. If eclib was just imported to the Sage sources, I doubt if it would become such a successful independent library. Singular has quite a few examples of these too. Omalloc, the memory manager, and factory, multivariate polynomial factorization library, were both written independently. They were imported into the Singular sources. Over time, the boundary between these got blurred. Now the Singular team is spending considerable effort trying to refactor the code to expose these as separate units. On Tue, 15 Jan 2013 14:51:57 -0800 Robert Bradshaw <rober...@gmail.com> wrote: > > Do we really need to coordinate these? Why is Sage any > > different from any other large software package out there? > > > > The standard solution to this problem is to add a "configure" > > script to the library which checks if the dependencies are > > satisfied and sets various options for the compilation process > > accordingly. > > > > For better or for worse, Sage couples very tightly with (and even > patches) its dependencies, and while moving away from this is a noble > goal I don't foresee it happening any time soon (at least I don't > want to postpone our development model until we get there). > Eventually the dependencies could be "see if X is on the system" > rather than "install this (s)pkg" on a package by package basis. How does moving to proper DVCS based development relate to merging the repositories? How many tickets on trac touch more than one repository? What is the disadvantage of adding "see if X is on the system" type checks in the Sage library right now? > > The initial design of Sage separated the mathematics library > > from the distribution system, then further separated the user > > interface (notebook) from the mathematics library. Why are we now > > trying to reconcile a bunch of shell scripts with a Python/Cython > > library for mathematics? > > > > Because drawing (really, creating and then enforcing) a line between > them is hard (it's certainly not in the right place now), and I don't > see either one taking a life of its own without the other. Also, > maintaining and developing on N repositories is much more painful for > any value of N > 1. Sage's build system almost took life of its own in the past. Ondrej used it for FEMHub for instance. There are quite a few projects for packaging scientific software these days. So "life" is clearly possible in this area. Merging everything in one repository would just make the distinctions disappear over time. Making these distinctions clear is better software practice. It would make maintenance easier over time. Cheers, Burcin -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To post to this group, send email to sage-devel@googlegroups.com. To unsubscribe from this group, send email to sage-devel+unsubscr...@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en.
