On Thu, Jun 3, 2010 at 9:21 PM, William Stein <[email protected]> wrote: > On Thu, Jun 3, 2010 at 9:07 PM, Ondrej Certik <[email protected]> wrote: >> Hi, >> >> On Thu, Jun 3, 2010 at 8:44 PM, William Stein <[email protected]> wrote: >>> On Thu, Jun 3, 2010 at 5:09 PM, Ondrej Certik <[email protected]> wrote: >>>> Hi, >>>> >>>> we are revisiting prerequisites for FEMhub (currently based on the >>>> Sage system) and we are thinking of doing the following changes: >>>> >>>> * make Python a build dependency (Python will still be built and used >>>> as the python in FEMhub) >>> >>> So there has to be a system-wide Python, but you'll still build your >>> own. I personally >>> think that is a great idea. >>> >>>> * make bzip2 a build dependency (I checked and it seems to be on the >>>> Mac by default now too) >>> >>> Sage has this as a dependency for at least two reasons: >>> >>> (1) to get the bunzip2 binary, so we can extract spkg's. >>> >>> (2) for libbz2 and corresponding header files, so that we get the >>> bz2 Python module, which we use for compressing our "sobj" files >>> (which are just bz2 compressed Python pickles). >> >> Yes, >> >>> >>> I don't know of any other way in which we use bzip2. For FEMHUB (2) >>> might not matter. I suspect regarding (1) that the bunzip2 is a very >>> reasonable prerequisite to assume is installed on your user's >>> computers. >> >> The only question that I am actually asking is whether: >> >> a) bzip2 should be shipped and build with Sage >> >> or >> >> b) bzip2 should be a prerequisite just like m4/gcc/perl >> >> In either case, both 1) and 2) would work. Unless I am missing something. > > You are missing something. There is a difference between having the > bzip2 (and bunzip2) binaries on a system, and having the development > headers and libraries available. I don't want to make the bzip2-dev > headers a prerequisite for building sage.
Ah, I didn't realize that I need bzip2-dev too. In this case I think I'll create a bzip2 spkg package (with the headers), that I will install before Python (as any other package in Sage/FEMhub) and things should just work (as long as bzip2 binary is available on the system). Ondrej > >>>> * create a simple (order matters) list with packages to be installed, >>>> and the Python build system would install it one by one (sequentially) >>>> using "femhub -i". >>> >>> This would avoid having to use the makefile system we use. We can't >>> do this with Sage because it would make inplace upgrades of Sage more >>> difficult, right? Maybe you don't support this with FEMHUB, so it >>> doesn't matter? >> >> Yes, we don't support this. >> >>> >>> I actually wrote the first version of the Sage build system entirely >>> to support in-place upgrades, because David Kohel in Australia had >>> very limited bandwidth. (It used to be really bad in Australia.) >> >> I actually totally forgot about this possibility. I guess that in >> principle the (Python based) buildsystem can support this too somehow, >> but it would make it more complex, that's for sure. > > You could certainly implement dependency checking in Python, and get rid of > the makefiles (deps). I used make initially only because it was > available and easy. > >> >>> >>>> * simplify spkg/base, remove spkg/install, spkg/default/dep >>> >>> That's basically the previous step. >>> >>>> So I wanted to ask, if bzip2 should still be shipped with Sage, or if >>>> it can be made a prerequisite, just like m4, gcc and perl. >>> >>> We will continue to ship it with Sage. However, I can certainly see >>> you removing it from FEMHUB. >> >> Originally I wanted to have it so that Sage can use it too, but as I >> see it now, here is my plan: >> >> * remove the Sage buildsystem completely (all makefiles, install, >> dep), as well as the spkg/base dir >> * keep sage-spkg and sage-env, possibly modify it so that it still >> works (maybe some more scripts need to be kept) >> * ./femhub (the equivalent of ./sage) would call either the systemwide >> Python (during installation) or the builtin Python (after >> installation) >> * write a Python based buildsystem that uses sage-spkg to install a package >> >> So the only thing that will remain compatible with Sage are the actual >> packages, so if I provide the list of packages in Sage instead, it >> should build Sage just fine. > > -- A big +1 to remaining compatible with the spkg format. > >> >> After this is done, I'll see how it goes (and if we like it) and we >> can think again, if it's possible to extend it so that it could be >> used in Sage itself. If not, I think it will not be a problem for us >> to maintain this buildsystem separately. > > That sounds good to me. > > -- William > >> >> Ondrej >> >> -- >> To post to this group, send an email to [email protected] >> To unsubscribe from this group, send an email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/sage-devel >> URL: http://www.sagemath.org >> > > > > -- > William Stein > Professor of Mathematics > University of Washington > http://wstein.org > > -- > To post to this group, send an email to [email protected] > To unsubscribe from this group, send an email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/sage-devel > URL: http://www.sagemath.org > -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
