> 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. >
We could go on about package theory for a while here. Just to make sure I got my point across, sage -b(xx) would work on the clone. > > > - 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. > OK. > > 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. > OK. > There is a mercurial repository which you can pull from in > > http://sage.math.washington.edu/home/burcin/portage > If we are seriously working on this I'll be more concerned about finding somewhere to host a clone and push [google code comes to mind] Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- 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
