Repository / Build System Restructuring Information

Your ideas regarding restructuring are important. You may edit this page and leave a signature, or send your comments to cesrulib@mail.lepp.cornell.edu

The ACC repository will be reorganized and renamed to accomodate all accelerator-related code development and documentation. The new repository will be named 'ACC' to signify this.

In order to bring about this change, the existing ACC repository will be restructured, incorporating previously isolated projects in the process.

This meeting will include the discussion of the following:

Repository Reorganization

• How may the organization of the repository be best changed to simplify or enhance development efforts?
  • Is there a particular structure of files / directories / modules that makes the most sense to you in terms of building and linking software units together?
  • Does an obvious logical hierarchy exist under which all current and future software units may be inserted smoothly?
  • Is there any logical structure that would better reflect dependency issues between software units? Is this at all important?
• Are there files other than source code that would benefit from being kept in the ACC repository?
  • How would these be organized?
• What additional projects exist that would benefit from being relocated to the master repository?
• What "projects" or lines of development should be included and how should they be arranged with respect to one another?
• Possible Repository Organization Scheme

Build System Restructuring

• Is there anything broken, awkward, or substandard within the current build system?
  • There is currently a master library-file and Fortran module area for builds, so that every library or application being built knows to look in this catch-all area.
    • Is this a problem? Are there good alternatives to this approach?
  • Currenting using makedepend, the use of which is essentially deprecated
  • Is it necessary to provide for recursive builds through subdirectories in a given project?
    • Can a better system of organization be imposed within library code bases?
• What general changes could be made to eliminate some or all of the above issues?
  • Tweak or overhaul existing makefile / perl / shell script approach to enhance flexibility and robustness
    • Not obvious yet what this might entail
    • Possibly already near limits of practical extensibility
  • New build system entirely
    • Possiblity of using GNU autotools -- autoconf, automake and the like?
      • looking into this possibility, but lengthy testing will be required to properly evaluate, due to multiple languages & complexity
    • SCons - Python-based flexible build engine
      • Currently experimenting with build system design
      • Documentation has yet to catch up with feature set, but...
      • Looks promising
        • Supposedly handles building and dependency generation for C/C++ and Fortran 77/90/95 out of the box using well-known compilers including Intel Fortran
    • cmake - Cross-platform make system
• This outline will be discussed at the next accelerator computing meeting scheduled for the 26th of January, 2007.
  • See the list of suggested meeting attendees in these previous meeting notes.

-- MattRendina - 17 Jan 2007

• Source_Code_Repository_Restructuring_1-30.ppt: Updated restructuring proposal slides