#12102 closed enhancement (fixed)
Make bzip2 a standard (instead of base) package
Reported by: | jdemeyer | Owned by: | tbd |
---|---|---|---|
Priority: | major | Milestone: | sage-5.0 |
Component: | packages: standard | Keywords: | |
Cc: | Merged in: | sage-5.0.beta11 | |
Authors: | Jeroen Demeyer | Reviewers: | John Palmieri |
Report Upstream: | N/A | Work issues: | |
Branch: | Commit: | ||
Dependencies: | #12479, #10492, #12602 | Stopgaps: |
Description (last modified by )
Now that we have support for gzipped Sage packages (#12602), we can easily make bzip2
a standard package instead of a base package. This will further the goal of decreasing the number of base packages (ideally to zero), see also #12631.
spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/bzip2-1.0.6.spkg (bzip2 compressed, to be converted to gzip when merged)
apply 12102_bzip2_standard.patch to SAGE_ROOT
.
delete the untracked file spkg/base/bzip2-1.0.5.tar.gz
.
Attachments (1)
Change History (18)
comment:1 Changed 10 years ago by
- Dependencies set to #12602
comment:2 Changed 10 years ago by
- Dependencies changed from #12602 to #12479, #10492, #12602
comment:3 Changed 10 years ago by
- Description modified (diff)
comment:4 Changed 10 years ago by
- Description modified (diff)
comment:5 Changed 10 years ago by
- Description modified (diff)
Changed 10 years ago by
comment:6 Changed 10 years ago by
- Description modified (diff)
comment:7 Changed 10 years ago by
comment:8 Changed 10 years ago by
If you want, it's ready for review. But to be honest, I haven't really tested it.
comment:9 Changed 10 years ago by
- Status changed from new to needs_review
comment:10 follow-up: ↓ 11 Changed 10 years ago by
I see that the old package compiles with commands like this:
gcc -fPIC -c blocksort.c
while the new one compiles with
gcc -fPIC -O2 -g -c blocksort.c
-O2
seems like a fine idea, but do we need -g
? I don't know much about debugging: since this is a pretty well-established package, there aren't like to be bugs in it, so can we omit -g
, or would that mess up debugging for other parts of Sage? Should we add a test for SAGE_DEBUG
so that we at least have the option to turn it off? I notice that the new libbz2.a
is more than twice the size of the old one, at least on sage.math.
comment:11 in reply to: ↑ 10 Changed 10 years ago by
Replying to jhpalmieri:
-O2
seems like a fine idea, but do we need-g
?
I thought it was "standard practice" to compile all Sage packages using -g
(regardless of SAGE_DEBUG
). With GCC, files only get larger when compiled with debug information, but the code is exactly the same. So programs should run equally fast with or without debugging information (except for the I/O effects of having larger files).
comment:12 Changed 10 years ago by
- Reviewers set to John Palmieri
- Status changed from needs_review to positive_review
It looks to me as though SAGE_DEBUG
is used somewhat inconsistently. Since William (among others) is concerned about the size of the Sage distribution, I think at some point we should consider not using -g
. Maybe don't use it for bdists
? Anyway, this is not something that should be decided here, and I'm happy with the changes in this ticket.
comment:13 Changed 10 years ago by
Let me mention that I also tested upgrading from sage-4.5 and sage-4.8, no problems.
comment:14 Changed 10 years ago by
- Description modified (diff)
comment:15 Changed 10 years ago by
- Merged in set to sage-5.0.beta11
- Resolution set to fixed
- Status changed from positive_review to closed
comment:16 follow-up: ↓ 17 Changed 10 years ago by
By the way, the file spkg/base/README.txt
should be modified to reflect this change. Is the directory spkg/base
going to disappear altogether soon? If so, we don't have to worry about this.
comment:17 in reply to: ↑ 16 Changed 10 years ago by
Replying to jhpalmieri:
By the way, the file
spkg/base/README.txt
should be modified to reflect this change.
Going to do this in #12631.
Is the directory
spkg/base
going to disappear altogether soon?
Probably not. Eventually, I would like prereq to become a top-level ./configure
for Sage, but I haven't thought nearly enough about this to see how that would work.
Is this ready for review?