This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
development plans, priority items for 3.1
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org, mark at codesourcery dot com
- Date: Fri, 4 Jan 2002 17:14:19 -0800
- Subject: development plans, priority items for 3.1
The roadmap for the gcc-3.1 release is specified here:
http://gcc.gnu.org/develop.html
Salient dates are:
2002-02-15 GCC 3.1 Stage 3 ends, branch created
2002-04-15 GCC 3.1.0 Release.
This roadmap specifies a nice orderly progression for the compilers,
but the target libraries are unspecified. Here's a suggestion for the
library: comments are welcome!
Goals:
1) Get ABI-breaking changes in ASAP
I'm sure we can throw around more acronyms here, if necessary. I'm
proposing a date of Feb 05, 2002 for getting in larger,
binary-change-type patches. I think this is reasonable. Thoughts? It's
important to me to position gcc-3.1 as a long-lived ABI. (Since Red
Hat and presumably SuSe, Apple, others, will be using it for OS
releases.)
2) Close outstanding GNATS bugs
Good progress on this in the last month!
3) Complete more doxygen man pages, get more coverage on doxygen markup.
Phil made a release of the current-work. I suggest people check it out:
ftp://gcc.gnu.org/pub/libstdc++/doxygen/
I fully support the markup of the headers for this work. I'm playing
around with the indexes, and trying to figure out alternative
organization for names and symbols: maybe by chapter? Is that too
lame? Not stylish enough? It might be nice, if possible, to break
apart required names and symbols from implementation bits (ie __x or _X
names).
4) Get more coverage in testsuite.
Particularly weak is 23_containers. Although it's not the most
glamorous thing, this is quite helpful. Coverage has increased by
about 100 tests between gcc-3.0 and gcc-3.1, which is really quite
nice.
5) Benchmark and tune.
Getting some kind of infrastructure in place to do this will be my
high priority around Feb, 2002. I hope others beat me to it. It would
be great to have the following metrics:
1) execution speed
2) binary size, static and shared
3) compilation time
4) memory usage
It's quite a wish list, but it would be useful. Loren, Paolo, and
Nathan have already done some good work in this area.
-benjamin