[SCM] GiNaC -- a C++ library for symbolic computations branch, ginac_1-5, updated. release_1-4-0-188-g7e14533
This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "GiNaC -- a C++ library for symbolic computations". The branch, ginac_1-5 has been updated via 7e145335f2d185c7e07044be5a758bb8f0f71e29 (commit) from 0256e2fe48a0ecce79c37ac209620ca852b7f11a (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit 7e145335f2d185c7e07044be5a758bb8f0f71e29 Author: Jens Vollinga <jensv@nikhef.nl> Date: Wed Feb 25 13:07:18 2009 +0100 Preparing for release. ----------------------------------------------------------------------- Summary of changes: NEWS | 4 ++++ configure.ac | 10 ++++++---- 2 files changed, 10 insertions(+), 4 deletions(-) hooks/post-receive -- GiNaC -- a C++ library for symbolic computations
Hi, On Wed, Feb 25, 2009 at 01:03:40PM +0100, Jens Vollinga wrote:
- Log ----------------------------------------------------------------- commit 7e145335f2d185c7e07044be5a758bb8f0f71e29 Author: Jens Vollinga <jensv@nikhef.nl> Date: Wed Feb 25 13:07:18 2009 +0100
Preparing for release.
-----------------------------------------------------------------------
Summary of changes: NEWS | 4 ++++
--- a/NEWS +++ b/NEWS @@ -1,5 +1,9 @@ This file records noteworthy changes. +1.5.1 (25 February 2009) +* Fixed compiling problems with GNU g++ 3.4. +* Fixed broken RTTI on woe32. + Oh, what a nice joke! @@ -14,7 +14,9 @@ dnl When making releases, do dnl 1. Increment ginac_lt_revision dnl 2. If any interfaces have been added, removed, or changed since the last dnl release, increment ginac_lt_current and set ginac_lt_revision to 0. -dnl 3. If any interfaces have been removed since the last release, set +dnl 3. If any interfaces have been added since the last release, increment +dnl ginac_lt_age. +dnl 4. If any interfaces have been removed since the last release, set dnl ginac_lt_age to 0. dnl So far so good... @@ -22,8 +24,8 @@ dnl systems, the numbering is consecutive. It only guarantees that it is dnl increasing. This doesn't matter, though: there is not incurred cost dnl for numbers that are omitted, except for shrinking the available space dnl of leftover numbers. Not something we need to worry about yet. ;-) -m4_define([ginac_lt_current], [0]) -m4_define([ginac_lt_age], [0]) +m4_define([ginac_lt_current], [1]) +m4_define([ginac_lt_age], [1]) m4_define([ginac_lt_revision], [0]) This looks incorrect. We did not add or removed any interfaces, we fixed existing ones. So we should simply increment ginac_lt_revision, and that's it. Best regards, Alexei
Hi, Alexei Sheplyakov schrieb:
+1.5.1 (25 February 2009) +* Fixed compiling problems with GNU g++ 3.4. +* Fixed broken RTTI on woe32. +
Oh, what a nice joke!
what do you mean? Should we change NEWS?
-m4_define([ginac_lt_current], [0]) -m4_define([ginac_lt_age], [0]) +m4_define([ginac_lt_current], [1]) +m4_define([ginac_lt_age], [1]) m4_define([ginac_lt_revision], [0])
This looks incorrect. We did not add or removed any interfaces, we fixed existing ones. So we should simply increment ginac_lt_revision, and that's it.
But crc32(), crctab[], make_hash_seed() are part of the (public) interface, or not? Regards, Jens
On Wed, Feb 25, 2009 at 01:46:41PM +0100, Jens Vollinga wrote:
Alexei Sheplyakov schrieb:
+1.5.1 (25 February 2009) +* Fixed compiling problems with GNU g++ 3.4. +* Fixed broken RTTI on woe32. +
Oh, what a nice joke!
what do you mean?
`Fixed broken RTTI on woe32' is a bit sloppy. It might be (mis)interpreted as if we fixed woe32's C++ runtime library itself instead of accommodating GiNaC to its limitations. Hence it sounds a little bit funny.
Should we change NEWS?
Yes. I propose the following wording: * Work around weird C++ RTTI behaviour on woe32 so GiNaC works on MinGW again.
-m4_define([ginac_lt_current], [0]) -m4_define([ginac_lt_age], [0]) +m4_define([ginac_lt_current], [1]) +m4_define([ginac_lt_age], [1]) m4_define([ginac_lt_revision], [0])
This looks incorrect. We did not add or removed any interfaces, we fixed existing ones. So we should simply increment ginac_lt_revision, and that's it.
But crc32(), crctab[], make_hash_seed() are part of the (public) interface, or not?
crc32(), make_hash_seed() are not exported via user visible headers so they are not part of public API/ABI. Also, these functions (and crctab[] variable) are static. They can't be a part of the public interface in first place. Best regards, Alexei
participants (3)
-
Alexei Sheplyakov
-
git＠ginac.de
-
Jens Vollinga