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]

Re: [libstdc++] doc/xml/manual/abi.xml -- fix references to GCC as well as GNU/Linux


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]