This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
On 4 December 2011 21:08, Gerald Pfeifer wrote: > Hi Jonathan, > > On Sat, 3 Dec 2011, Jonathan Wakely wrote: >> How's this? ?I think I got all the versions and dates correct, but I >> must say I find keeping some of this info in the manual to be tedious >> and unnecessary. > > I agree, there is (too) much detailed and extra contents there > which does not actually strike me as helpful. > >> To deal with the tedious parts, I changed a few repetitive instances >> of 4.1.0, 4.1.1, 4.2.0, 4.2.1, 4.3.0 etc. etc. to just 4.x.x which >> will be accurate in future and can be changed if it needs to be, >> rather than having to keep adding new entries that say the headers for >> GCC 4.6.1 are in include/c++/4.6.1 and, guess what, the headers for >> GCC 4.6.2 are in include/c++/4.6.2 >> >> Would 4.*.* or 4.?.? be better than 4.x.x? > > How about 4.x.y, to indicate that the second and third components > can be different? > >> I'm not sure why we need to explicitly state the libgcc soname for >> every release when it's always the same. > > Good point. ?In fact, looking at your patch and the document, could > you just remove the third component in all cases (or nearly all)? ?It > occurs to me that GCC 4.x, for fixed value of x, should be compatible, > if not identical in terms of characteristics, shouldn't it? > > That would strike me as even more of a simplification. > > And in those cases in your patch where it refers to GCC 3.3.x, for > example, it can just be GCC 3.3, so this also applies to regular > text, not just the tables. > >> If noone objects to this approach I'll regenerate the HTML pages and >> check this in at some point in the next few days. >> >> If anyone objects, please find a volunteer to keep the tedious version >> up to date ;-) > > I think with my proposal it'll become less tedious? :-) Yep, here's another patch with some more duplication removed. WIth this, the document only needs to be updated when a new symbol version is added or a library filename changes, not for every point release with identical library versions. I think I'm quite happy with this and will commit in a couple of days if noone objects.
Attachment:
abi_versions-2.txt
Description: Text document
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |