On Mon, Feb 20, 2012 at 12:39 PM, François Bissey <francois.bis...@canterbury.ac.nz> wrote: > On Mon, 20 Feb 2012 09:33:27 Robert Bradshaw wrote: >> On Mon, Feb 20, 2012 at 8:06 AM, Burcin Erocal <bur...@erocal.org> wrote: >> > Hi Keshav, >> > >> > thanks for pointing out this thread. "log messages" is an interesting >> > title to discuss the future directions for Sage. :) I added >> > gentoo-science to the CC list, since that is the most likely location >> > for sage-on-gentoo discussion and the gentoo-developers might be >> > interested in the contents of this thread. >> > >> > On Mon, 20 Feb 2012 22:45:24 +0800 >> > >> > Keshav Kini <keshav.k...@gmail.com> wrote: >> >> Robert Bradshaw <rober...@math.washington.edu> writes: >> >> > On Fri, Feb 17, 2012 at 1:09 AM, Keshav Kini >> >> > >> >> > <keshav.k...@gmail.com> wrote: >> >> >> Robert Bradshaw <rober...@math.washington.edu> writes: >> >> >> In the category of "glue code" I meant to include everything in >> >> >> $SAGE_LOCAL/bin/sage-*. I see much of that stuff as more related >> >> >> to >> >> >> maintenance of the entire distribution of software we ship than >> >> >> to >> >> >> the actual Python/Cython code in the Sage library. Of course, if >> >> >> we do switch to Prefix or something like it, most of it will >> >> >> become >> >> >> unnecessary, or can actually be fit into the portage data tree >> >> >> as >> >> >> "Tools", so I see your point. >> >> > >> >> > Yeah, tools describes it well (or at least what remains after the >> >> > package management stuff is gone, like testing and coverage and >> >> > stuff). >> >> >> >> Well, I meant that there is a "Tools" directory in sage-on-gentoo. I'm >> >> not sure if this is a standard thing in the directory structure of a >> >> Gentoo Prefix tree, or, if it is, what sort of stuff is supposed to go >> >> there, but I see some utility scripts, presumably written by François >> >> or Christopher, in there and was suggesting we might be putting our >> >> sage-* scripts there too. But I don't know enough about Prefix to be >> >> sure whether that makes sense. >> > >> > AFAIK, Tools contains the scripts that are used to maintain the >> > overlay. sage-on-gentoo contains these packages for Sage: >> > >> > sage-baselayout >> > sage-clib >> > sage-data-conway_polynomials >> > sage-data-elliptic_curves >> > sage-data-graphs >> > sage-data-polytopes_db >> > sage-doc >> > sage-extcode >> > sage-flasknotebook >> > sage-notebook >> > sage >> > >> > baselayout is what gentoo calls basic scripts. That is the package >> > containing the relevant part of sage-scripts. While I like the >> > separation of the data packages (I assume these don't depend on code >> > from the sage library), I am not sure about the clib, doc and the >> > library separation. I'd like to keep those together to match the Sage >> > development pattern as close as possible. >> >> Both clib and doc were once separate spkgs. It was painful, and >> contributions to both were very low (and rarely did a change to clib >> not require a parallel change to the library). IMHO, there's no reason >> for extcode to be its own package either--I can't think of a single >> time I have modified extcode without modifying (usually extending) the >> sage library. Of course I've been advocating putting "baselayout" into >> this common repository as well. >> >> On the nix front, I love the ideas, but have never actually used it >> myself so have no idea about it's maturity (whereas sage-on-gentoo >> obviously works). >> > > OK. I must say I had started to ignore this thread until it landed in gentoo- > science. Not sure my cross posting will work as I have posting to gentoo- > science from this address (not sure why). > > I'll just adress the matter of the separation of clib, sage and doc. > clib and sage are an obvious separation package wise for us and an essential > step forward in the general quality of ebuild. Why? > Because in a package we separate the phases: > patching/preparing > configuration > compilation > installation > merging to the actual system > optionally test > > when you put clib and the sage library together you have technically to go > through two sets of install one after the other - for some package which > can be compiled with different sets of parameters this can usually be done in > parallel. But in the case of the sage spkg you have to go through the cycle > twice one after the other not in parallel. The nice theory say that you should > only do that kind of things once per package which is why it is separated.
It's only structured the way it is because it used to be a separate spkg. It's not so much a prerequisite for Sage as the C parts of the Sage library that could be built with the Sage library itself. My bias, however, is to get the simplest environment for Sage development, especially for newbies, and syncing or even knowing that there are distinct, tightly coupled repositories is unhelpful to this end. As an asside, just browsing the code, it looks like most of it could be easily implemented as a standard Cython module, is now obsolete (ntl_wrap) or should eventually be obsolete (it'd be really great to get interrupt signal handling into Cython itself). Of course who knows how long it'll take 'till anyone does that cleanup. > For the doc. There are several aspect to it. One is I am not sure the current > separation is good. I think the sphinx file that constitute the sage help > system on the comand line probably should be put back in the sage ebuild. > That would leave the doc ebuild only catering for html and pdf. > The second point is of course that we are currently fetching the html and pdf > doc rather than building it. It hasn't always been the case. It was a > conscious decision which lead to the separation on the ground that generating > the doc is quite slow. > There are efforts to parallelize the building of the doc and I would say that > if it gets merged we may very well put the doc back into sage and just build > it. We could keep fetching pre-built doc for thos who want on slow systems. I'd say building the docs sounds more like a USE flag, though a huge +1 to parallelizing it. - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
