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.

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 was discussed at the accelerator computing meeting on 26th of January, 2007.
  • See the list of suggested meeting attendees in these previous meeting notes.

• Source_Code_Repository_Restructuring_1-30.ppt: Updated restructuring proposal slides

System Reorganization

For security (and simplicity), the repository will only be accessible over https.

Important Changes

Users should take special note of the following changes

System or disk	Change
/nfs/cesr/[libs,user,temp]	move to /nfs/acc/[libs,user,temp]
\\lnx209\user samba share	move to \\accfs\user
\\lnx209\libs samba share	move to \\accserv\libs
ACC CVS Repository	move to ACC SVN Repository served over https
lnx6166	upgrade to dual-processor dual-core 3.2GHz system with 4GB memory, running SL4

Final setup

Primary Accelerator Systems

Node name	Function	Details
accserv (lnx209)	Repository & Libraries	/nfs/acc/libs (400G), https://accserv.classe.cornell.edu/svn/ (400G)
accfs (lnx113)	Primary Fileserver Experimental Disk Backup	/nfs/acc/user (500G), /nfs/acc/temp (2T) /mnt/auto/duple (1TB), /mnt/auto/delta (1.5TB)
cesrbuild1 (lnx6166)	Primary ACC Build machine
cesrbuild2 (cesr68)	OSF ACC Build machine
cesrbuild3 (pc6115)	Windows ACC Build machine
erlbuild (erd101)	Primary ERL Build machine	/nfs/erl/erd

Secondary (additional) Systems

Node	Details
lnx106	/nfs/grp/cesr (100G) - Opera
lnx156	disk backup (1.5TB)
lnx180c	/nfs/cesr/instr (37G)

Backup Strategy:

1. /nfs/acc/user
   • rsync backup to disk on lnx156
2. /nfs/acc/libs & repository
   • experiment with rsync backup to disk on lnx113
   • continue backup to tape (at least initially)

Next Steps

1. open port 443 through lnsfw to lnx209, making repository accessible from offsite