Ticket #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: | Work issues: | ||
| Report Upstream: | N/A | Reviewers: | John Palmieri |
| Authors: | Jeroen Demeyer | Merged in: | sage-5.0.beta11 |
| Dependencies: | #12479, #10492, #12602 | Stopgaps: |
Description (last modified by jdemeyer) (diff)
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
-
12102_bzip2_standard.patch
(3.7 KB) -
added by jdemeyer 15 months ago.
Change History
comment:2 Changed 15 months ago by jdemeyer
- Dependencies changed from #12602 to #12479, #10492, #12602
- Authors set to Jeroen Demeyer
comment:8 Changed 14 months ago by jdemeyer
If you want, it's ready for review. But to be honest, I haven't really tested it.
comment:10 follow-up: ↓ 11 Changed 14 months ago by jhpalmieri
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 14 months ago by jdemeyer
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 14 months ago by jhpalmieri
- Status changed from needs_review to positive_review
- Reviewers set to John Palmieri
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 14 months ago by jdemeyer
Let me mention that I also tested upgrading from sage-4.5 and sage-4.8, no problems.
comment:15 Changed 14 months ago by jdemeyer
- Status changed from positive_review to closed
- Resolution set to fixed
- Merged in set to sage-5.0.beta11
comment:16 follow-up: ↓ 17 Changed 14 months ago by jhpalmieri
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 14 months ago by jdemeyer
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.
