1 / 20

SCRAM

SCRAM. Information on SCRAM J.P. Wellisch, C. Williams, S. Ashby. BuildFile. Requirements Document. BootStrap. <Use name=fred> <External ref=X11>. BootStrap. BuildFile. <doc type=BootStrap> <base cvs=//cvsbase/abs>. BootStrap. <doc type=BootStrap> <base cvs=//cvsbase/abs>.

rowland
Download Presentation

SCRAM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SCRAM Information on SCRAM J.P. Wellisch, C. Williams, S. Ashby

  2. BuildFile Requirements Document BootStrap <Use name=fred> <External ref=X11> BootStrap BuildFile <doc type=BootStrap> <base cvs=//cvsbase/abs> BootStrap <doc type=BootStrap> <base cvs=//cvsbase/abs> <Use name=fred> <External ref=X11> <doc type=Requirements> <base url=cvs://cmsdoc.ce..> <require name=HelloWorld version=1.0> BuildFile <doc type=BootStrap> <base cvs=//cvsbase/abs> <Use name=fred> <External ref=X11> A SCRAM Managed Project SCRAM PROJECT Configuration Management Source code Distribution BuildSystem Configuration • scram_version

  3. Part of a component system • Interfaces towards • Code management • Change management • Binary distribution • Dependency analysis • Coding rule and style rule analysis • Software QA • Metrics • Integration • validation • Etc..

  4. Configuration management • Based around the following concepts: • PBS (Product break-down) • Product specification • Product versioning • Configuration definition and versioning • Product-wise configuration specification • ABS (Assembly break-down)

  5. The key to success • Configuration swim-lanes • Scram allows to define a set of internally compatible swim-lanes of configuration • These are backwards compatible extensions of the starting configuration of the swim-lane. • These are indispensable for staged mass production through the full chain of generation, simulation, reconstruction and analysis, where part of the code is developed, while other parts are already in production use.

  6. CLHEP 1.7 Installation Platform Application requires: CLHEP 1.5 Objectivity 5.2 NAG 3.1 X11 R6 Object..6.2 X11 R6 Linux 2.2 NAG 3.1 CLHEP 1.7 Installation Platform Object..6.2 X11 R6 SunOS 5.8 NAG 3.1 SCRAM resource mapping Application System Map SCRAM Information on target system is extracted and stored by SCRAM Linux 2.2 Installed Products

  7. BootStrap <doc type=BootStrap> <base cvs=//cvsbase/abs> Central Release Area Central Release Area Central Release Area SCRAM project development distribution model Describes project Site B Site C Site A Developers Areas

  8. Repository A Repository B Repository C Common Requirements Doc Project 1 Requirements Doc Project 2 Requirements Doc Project 1 Requirements Doc Common Requirements Doc Common Requirements Doc Project 2 Requirements Doc Requirements Document - Sharing Configurations between projects <include url=“RepositoryA:Common Requirements Doc”> Inlined by ActiveDoc PreProcessor • mechanisms to restrict the included configuration exist

  9. Project Configuration Requirements • Requirements Document • defines products and versions of external packages (tools) • tool description document (url) required for each tool • Refers to a configuration file in case of multi-project environment • Keep Consistent configurations between projects with a centrally maintained Configuration Document • mechanisms to restrict the configuration exist

  10. >scram tool list clhep 1.5 (default 1.5) objectspace 2.0 (default 2.0) objectivity 5.1.2 (default 5.1.2) Tool Configuration Management • SCRAMtOOLbOX • Each tool has its own configuration environment • Know exactly what product/version is being used • Finding which tools are available in the toolbox

  11. Tool Description Development • Development of tool description documents • Edit the apropriate file in .SCRAM/ToolFiles directory • e.g. CLHEP version 5.0 would be stored as clhep_5.0 • Run the tool setup command to initiate the changes • e.g. scram setup clhep 5.0 • To be useful outside of your area these documents should be made available on a server (e.g. cvs) so they can be accessed by the url mechanism

  12. BootStrap <doc type=BootStrap> <base cvs=//cvsbase/abs> SCRAM project installation 1. Client Downloads Document runs through SCRAM 2. BootStrap Document Published with each Release of a product 3. SCRAM assembles components described in BootStrap document into a designated Central Installation Area.

  13. Requirements Document <doc type=Requirements> <base url=cvs://cmsdoc.ce..> <require name=HelloWorld version=1.0> SCRAM project installation model (contd) 4. If a Requirements Document is specified, SCRAM tries to find the requested products on the client system or the site file, and creates a map in the Installation Area. 5. The client may, depending on the individual project, need to build the installation on the client system with the ‘scram build’ command.

  14. SCRAM project installation model (contd) 6. All OK? Then ... Freeze The Central Installation Area 7. Register the Installation in the scram database (‘scram install’ command). It is now ready for use

  15. Developer Areas • Isolated and well definedenvironment to develop code • Based against a central release area from which it can draw resources

  16. Creating a Developer Area • Area Creation - scram project >scram project ORCA ORCA_5_4_0 • Created in local directory • Directory Name has format • Name_Version Developer Area ORCA_5_4_0 (N.B. Removal of project name from version) scram project options : -n alternative_name - Specify a different name for the area -d directory - Create in directory specified rather than locally

  17. Environment Variables • Setting Up the environment - scram runtime >cd developer_area you should be in an area >eval `scram runtime -csh` use -sh for borne shells • Your environment is now set for the developer_area • Undoes the effect of any previous scram runtime command • (Makes it easy to switch between areas) • Instead of using eval you could redirect the output from the • scram runtime to a file which you could source when appropriate.

  18. Build System - BuildFiles • Can be anywhere in source tree • Used to override defaults, add additional build information, specify interfaces and dependencies. • Written as XML style documents >scram build • Performs the default build operations corresponding to • the current directory

  19. unit test BuildFile library src BuildFile Package BuildFile Package B BuildFile SubSystem BuildFile <Use name=fred> <External ref=X11> <Use name=fred> <External ref=X11> <Use name=fred> <External ref=X11> <Use name=fred> <External ref=X11> <Use name=fred> <External ref=X11> The BuildSystem Configuration Mapping subsystems packages src src test Build Configuration • BuildFile describes Build functionality

  20. BuildFile Library Class <Use name=fred> <External ref=X11> Profiled Shared Debug Shared Shared Debug Archive Profiled Archive Archive BuildSystem - Build Classes Example: BuildFile Requests a Class and sets parameters such as source code, library name, etc. Select a subset as a default build operation. Default can be overridden on the command line.

More Related