wiki:CsMapRfc8

Version 2 (modified by Norm Olsen, 10 years ago) ( diff )

--

CS-Map RFC 8 - CS-MAP Clean Up

Remove and/or delete as appropriate obsolete and unused source code modules and unused code. Includes removing same from make files and project files.

Status

RFC Template Version(1.0)
Submission Date09 May 2014
Last ModifiedNorm Olsen Timestamp
Author Norm Olsen
RFC Status Draft
Implementation Status
Proposed Milestone 14(?)
Assigned PSC guide(s)(when determined)
Voting History(vote date)
+1
+0
-0
-1
no vote

Overview

Over the years, CS-MAP has accumulated a lot of unused and obsolete code which is no longer necessary. This baggage has accumulated due to a variety of factors:

  • Being maintain by separate organizations and developers
  • Features being replaces by new RFC's.
  • Provisions for obsolete and/or non-standard operating system and compilers.
  • Old features maintained for legacy purposes which are now a liability rather than a positive.

The intent of this RFC is to itemize the proposed clean up efforts, have them reviewed and discussed, and upon final agreement, implement the clean up.

Motivation

Implementing this clean up will:

  • reduce the amount of code maintained,
  • reduce confusion to new users and developers,
  • remove unnecessary restrictions originally written in to accommodate obsolete platforms/OS/compilers
  • improve build times
  • reduce distributable sizes

Proposed Solution

The following is a list of items proposed for the clean up. Modifications, deletions, and additions are encouraged.

  • Remove the 'C' based CS_Test module. It hasn't been maintained and is rarely, if ever, used any more.
  • Delete (SVN meaning of Delete) pre-RFC-2 geodetic transformation code modules which are no longer referenced.
  • Remove all code pertaining specifically to Windows CE.
  • Correct all warnings issued by VC++ and gcc compilers.
  • Enhance make files for Windows and Linux so that single make command builds the entire product.
  • Remove all .gdc and .mrt files from dictionaries and distributions.
  • Modify the capitalization of file names so that all comform to a consist naming convention.
  • Rename modules and internal functions to names conforming to the base CS-MAP naming convention.
  • Implement pre-compiled headers where ever possible in make/project files.
  • Re-organize the csTestCpp test module to better reflect the actual usage for the product (i.e. Categories in, Groups out, 3D coordinate testing, etc.)

Implications

I submit this as an RFC as it is likely that some of the changes may require an tweak or two external to the library itself. And also, a project such as this needs a lot of testing in different environments. Without the support of the entire community, embarking on this worthwhile project could be dangerous. Assuming that no one is using the CS-Test.c module, and that few (if any) use modules below the EXP_LVL1 external interface, no external changes are envisioned, BUT . . .

Implementation Plan

Each of the above listed items will be implemented, tested, reviewed, and submitted separately to the extent possible. The easiest and safest will be performed first. The following are considered to be the easiest and safest:

  • Remove the CS_Test module.
  • Delete RFC-2 left overs from the repository and remove all reference in project/make files.
  • Remove unused .gdc and all .mrt files from the distribution and code (i.e. the Dictionary compiler).
  • Remove the remaining .gdc files which are still used (Vertcon and Geoid Height), replacing them with the concept of simply using whatever files exist in a predefined folder.
  • Modify the names of source code modules to comply with the basic CS-MAP naming convention. (Changes to module names, and hence changes to make/project files only. Function/Interface names remain unchanged.)

Test Plan

The existing, then the improved, csTestCpp module will be used to verify computational results remain the same and that basic features retain functionality and performance.

Funding/Resources

Hopefully, the primary patrons of the library will contribute funding and/or personnel resources to support some or all of these efforts. In absence thereof, Norm Olsen will perform the work. In the latter case, the effort will take 12 or more months to complete.

Note: See TracWiki for help on using the wiki.