ISOcxx Package -- Feature Log, Problem Tracking and Support Log

Bug 001:  special treatment for C system headers		6 Aug 2002

Initial Report
------------------
gcc gives special treatment to system <headers> (e.g., those found in
/usr/include, etc.).  When ISOcxx takes control of such header inclusion,
the special treatment was lost.  This caused problems when such a header
did C-ish things (not acceptable to C++) such as:
	struct S  {
	  ...
	  sometype S;
	};
because this would compile outside SRT/ISOcxx, but not within.

Technical Points
-----------------
This can be addressed via a gcc-specific command-line flag:  replace
some of the -I flags with -isystem flags.

Repair Plans
-----------------
Do immediately.

Problem Rectified						7 Aug 2002
-----------------
Check-in delayed circa 24 hours due to unrelated Kerberos problem.


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


Enh. 001:  DEFECT_COMPLEX_INCOMPATIBLE

Statement of suggested enhancement				27 Feb 2002
----------------------------------
GCC 2.95.2 <complex> gets into an argument with /usr/include/math.h
on a Linux 7.1 system, resulting in compilation failure whenever a
compilation unit #include's both.  We wish to make this into a new
defect for ISOcxx to handle.

Technical Information					
---------------------
Inspection shows that the problem is a precautionary redeclaration,
in gcc internal header <complext>, of a non-standard function, hypot().
The redeclaration does not match the declaration in <math.h>, hence
compiler diagnostics result.

Decision
--------
Proceed in order that all Zoom packages can properly compile in this
environment.  Until this is done, any package using both <complex> and
<math.h> (i.e., CLHEP, SpecialFunctions, LinearAlgebra) will fail to
compile.

Plans and Priority
------------------
The usual ISOcxx mantra:  devise a test to detect the problem, insert
the test into configure.in (and list the test among the dependencies
within GNUmakefile), devise a cure for the problem, update the ISOcxx
documentation, test on all platforms.

Enhancement Done						4 Mar 2002
----------------

The cure for this problem is "preemptive":  the test program can no
longer even detect the defect!

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -


==================================================================

Bug 000: No bug problem

Initial Report					12/21/01
------------------
	Version 2.0

There are no bugs so we make one up to show how it is tracked.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Technical Points
-----------------

This is easy to fix.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Repair Plans
-----------------

Do nothing.

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

Problem Rectified				12/21/01
-----------------

  Version 2.0

===========================================================================

	ISOcxx Package -- Support Log

	   		Version Name Time Date    Comment
	
Enh. 001 COMPLEX_INCOMPAT        web 4.5  03/04/02 New defect
Bug  000 no bug problem   2.0    mf  0.0  12/21/01 Found no bug

===========================================================================

Activity		Prior Estimate		Time	Approx Dates
--------		--------------		----	------------
Enh 001			    ---			 4.5	  26 Feb - 4 Mar 2002
Bug 001			    0.0                  0.0	  12/21/01

===========================================================================

Types of entries:

Bug xxxx 		Version Name TimeSpent Date Comment
Port platform 		Version Name TimeSpent Date Comment
User user-names		Version Name TimeSpent Date Comment
Structural problem 	Version Name TimeSpent Date Comment
Documentation file	Version Name TimeSpent Date Comment
Enhancement number	Version Name TimeSpent Date Comment
Validation maintenance  Version Name TimeSpent Date Comment
Release note number

Entries in support log should mostly be a single line.
Time spent should be measured in FTE-days.