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.

>>> * 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

Reply via email to