On Tue, 3 May 2011 20:42:01 -0700 (PDT) François <francois.bis...@canterbury.ac.nz> wrote:
> On May 4, 5:23 am, Burcin Erocal <bur...@erocal.org> wrote: > > > > > One last thing about "sage -clone, -b, -ba, br, ..." --- from my > > > memory about several discussions, the sage community regards this > > > as a "killer feature", i.e. that there is not some "sage" and > > > then some other, different "sage-dev" package/distribution, but > > > only one. So the hurdle for any user to gradually become a > > > developer is made as low as possible. I have some rough ideas how > > > to make this possible "inside" a standard distribution with also > > > an eye on reliable package management, i.e. not restricted to > > > Gentoo/Gentoo Prefix, but also Debian and so on. But these ideas > > > would need thorough discussion. > > > > I agree that this is a killer feature. The prototype tarball does > > nothing about this problem. As I said earlier, I think we can > > reconfigure portage to use "devel/*" as the build directory, and > > hook up some internal portage commands to handle "make install" > > etc. Though I haven't tried any of this and I'd appreciate hearing > > any other ideas. > > > > I don't know what Georg has in mind. The current sage-on-gentoo > strip the hg repo so the first step will be to include that back. > Next I would like to keep the way it is installed now as it insure > integrity of the package for smooth upgrade. But once we put back > the hg repo we can create clones. In the developer guide it is > strongly > suggested to create a clone before doing whatever you want and then > you can > switch between clones or the main branch. I am basically suggesting > that > we enforce cloning for development. Perhaps we can add a function in ebuilds which sets up a development environment for the source. This would be similar to the way you can call post install configuration from ebuilds any time after it's merged. IIRC, the portage command for this was: ebuild <ebuild_file_name> config It would be best if this can avoid rebuilding the source. At some point we thought about adding an option to Sage to do this. Since setting this up for pynac, the notebook, etc. was getting to be an FAQ. > > - installs Volker's compiler wrapper using portage > > AFAICT, this wasn't absolutely necessary since I didn't try > > relocating the tree after the build. However, I can see that the > > singular built in the prefix uses the ntl libraries installed in > > the prefix instead of the ones on my system. This is an > > improvement over the current Sage build I have. > > > > Relocation aside I think the wrapper is still needed. Remember how > you first filed issues on github about stuff not found in the prefix? > The wrapper can help with that. > https://github.com/cschwan/sage-on-gentoo/issues/53 > https://github.com/cschwan/sage-on-gentoo/issues/52 If make.conf sets CFLAGS, etc. properly, then we can get away without the wrapper to build the packages in the prefix. I ran into the problem in those tickets because I was setting CFLAGS myself in make.conf, without explicitly specifying the prefix include and library paths. I somehow expected that to be handled automatically. I spent time including the wrapper, because I want the prefix to work as a development environment for mathematical software as well. If you work in the shell started by the startprefix script, things should work seamlessly and the compiler should look in the right places for header files and libraries. The wrapper solves this problem perfectly. > > - calls portage to install baselayout-prefix > > This is the package that provides files for the environment > > variables, etc. in the prefix. this pulls in: > > sys-libs/readline > > sys-apps/baselayout-prefix > > > > I don't know why readline is built here and not as a dependency > > of python. Perhaps there is a missing dependency in the gentoo > > ebuilds. > > Not sure. > > > > > - calls portage to install singular > > This pulls in: > > dev-libs/gmp > > dev-libs/gf2x > > dev-libs/ntl > > sci-mathematics/singular > > > > It would be be better to call "emerge -D singular" rather just > "emerge singular" may be that would take care of Volker's > problem. Actually Volker may very well suffer from the problem > you had above. Good point. It's been a while since I used emerge/portage actually. I switched to paludis long ago. I should have used "-D" while preparing the packages.provided file as well. I will have a go at doing this later. > > Comments? > > Well done so far. We need a repo. While we are putting this together > I'd like it if you added the following to etc/make.conf: > PORT_LOGDIR="${SBASE}"/var/log/portage > PORTAGE_ELOG_CLASSES="warn error info log qa" > PORTAGE_ELOG_SYSTEM="save" > FEATURES="split-log" > > That way we have a log record similar to the one produced by > sage when building spkg. I have a feeling we may need it. > The "split-log" means that the log will be sorted in folders > according > to categories (app-shell and so on) given the clutter generated that's > fairly useful. > I still build sage on a machine that doesn't have sse2 you know! It might be cleaner to add these to the make.defaults file for portage. Then we won't confuse the user with the extra lines in make.conf. I will revise the patch for make.defaults. There is a mercurial repository which you can pull from in http://sage.math.washington.edu/home/burcin/portage I will upload this to bitbucket today. Thanks for the feedback. Cheers, Burcin -- 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
