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
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.
- 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.
For security (and simplicity), the repository will only be accessible over https.
Users should take special note of the following changes
| System or disk
|| 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
|| upgrade to dual-processor dual-core 3.2GHz system with 4GB memory, running SL4
Primary Accelerator Systems
Secondary (additional) Systems
| Node name
| 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/grp/cesr (100G) - Opera
|| disk backup (1.5TB)
|| /nfs/cesr/instr (37G)
- rsync backup to disk on lnx156
- /nfs/acc/libs & repository
- experiment with rsync backup to disk on lnx113
- continue backup to tape (at least initially)
- open port 443 through lnsfw to lnx209, making repository accessible from offsite