<SNIP> > > Furthermore, I intend to help > > maintain the C algorithms. I fully intend to work on them actively if their > > speed is not sufficient. Making a seperate spkg dramatically increases the > > difficulty of active development. > > Why??? I could have said the same about Pyrex two years ago, and it would > have been silly. So could you please explain why this is true of glib-lite. > I'm not saying it isn't try! I just don't see why it should be. I know > you're extremely good at writing and arguing points, so please be patient > with me and explain why "Making a seperate spkg dramatically increases the > difficulty of active development." Again, I'm *not* at all sure I'm right! > And you've been much closer to that code than I am, so you're much more likely > to be right. That said, you've not given any argument, and this is the time > to work these things out -- that's why we have a vote, etc., for packages. > > -- William >
Having slept on the whole spkg vs. sagelib issue: I think doing glib- lite in an spkg might be a little more work right now, but it forces us [ehh Gary] to factor out the pbuild bits or write a makefile that uses a bunch of env variables determined by spkg-install. Sticking that in an spkg-install isn't that much work. Making the makefile independent of pbuild would also increase the chances that other projects would actually use the code. Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~----------~----~----~----~------~----~------~--~---
