History motivations
This presentation is the property of its rightful owner.
Sponsored Links
1 / 25

History, motivations PowerPoint PPT Presentation


  • 73 Views
  • Uploaded on
  • Presentation posted in: General

History, motivations. Started in 1993 for providing support for horizontal software development at LAL After an evaluation of the autoconf world, decision was taken to create a new package basic requirements were : emphasis on simplicity to use and to understand by non software experts

Download Presentation

History, motivations

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


History motivations

History, motivations

  • Started in 1993 for providing support for horizontal software development at LAL

  • After an evaluation of the autoconf world, decision was taken to create a new package

    • basic requirements were :

      • emphasis on simplicity to use and to understand by non software experts

      • should be based on a real conceptual model

    • study of works

      • SEI : definitions of Configuration Management (IEEE Std-729-1983)

      • Inspiration from the CMM (freely interpreted)

  • Promote Human Oriented Software


The configuration management definition

The configuration management definition

  • IEEE Std-729-1983

    “Configuration is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items”

  • Identification

    describes the system structure, the nature of its elements, their identity, and gives access to each item version

  • Control

    organises versions and changes to system items while keeping coherency and consistency on the complete system.


Principles of the package

Principles of the package

  • Based on some scenarios

    • Projects or sub-projects promote part of their software base as reusable

    • Projects are divided into small groups of closely related developers

    • Integration phases are iterative and must remain under the control of the package managers

    • Configuration parameters should be defined/specified independently to their implementation

    • Configuration parameters should be queried at any time outside of any effective software operation

    • Maintain several concurrently visible versions of each package

    • ...


Principles of the package1

Principles of the package

  • …and on some definitions and conventions

    • the package

      • the smallest autonomous entity in the software base

      • support use relationships to other packages

      • the physical organisation of packages is independent of their logical structure

    • the configuration parameters

      • identify and describe the constituents of a package

        • applications, libraries, …

      • set up the environment needed to develop the package

        • environment variables, make macros, include paths, …

      • set up the environment needed to operate the package

        • environment variables, aliases, setup scripts, …


Principles of the package2

Principles of the package

  • …and on some definitions and conventions

    • physical organisation

      <root1>/<package>/<version tag>/src

      /mgr

      /<conf. tag1>

      /<conf. tag2>

      <root2> >/<package>/<version tag>/src

      /mgr

      /<conf. tag1>

      /<conf. tag2>

      /...


Principles of the package3

Principles of the package

  • ...conventions

    • configuration tag

      • reflects the machine type, the operating system, the context (debug, gnu, etc…)

      • may be either automatically from system features (uname, fs sysname, …) or freely defined

    • Site tag

      • freely defined tag for site-dependent symbol values


Principles of the package4

Principles of the package

  • Operations

    • The configuration parameters are exploited by CMT to configure the various tools used during the software process activities, or to generate some documents:

      • CVS

        • chain the used packages

      • [g]make

        • transparent generation of all makefiles

      • MS Developer Studio

        • generation of workspace and project files

      • Unix shells

        • generation of environment variables, aliases, paths, etc...

      • Web pages

        • generation of the software configuration documentation


Conceptual and user requirements

Conceptual and user requirements

  • Packages are autonomous entities

  • Packages are related to each other by use relationships

  • Package evolution and history is specific to each package

  • Configuration parameters are any information required to

    • identify the constituents of the package

    • set up the environment needed to develop and operate the package

    • describe the use relationships between packages

  • Version tag semantics reflects backward compatibility or incompatibility

  • Configuration parameters are propagated through the chain of use relationships.

uses

uses

A

B

C


Design

Design

  • Based on the modelling of the configuration management parameters

    • one object model (used to build tools)

    • one syntax (used to make conf. Parameters persistent)

macro

use

n

symbol

alias

n

set

symbol_value

tag

n

setup_script

script

n

cleanup_script

generator

n

library

1

constituent

application

n

source_file

document


Implementation

Implementation

  • Parameters are stored and maintained within one textual file per package named requirements

  • Use a simple (easy to read) and homogeneous syntax

  • One basic parser application implements the object model from the textual representation (cmt_parser.exe)

  • One main user interface (cmt) to the parser provides the command oriented (à la CVS) interface used for

    • querying the configuration parameters

    • generate the effective environments

      • for package development

      • for package usage


Implementation1

Implementation

  • A Java browser

  • and editor

The package search list

Packages

Versions for this package

The requirements file

The used packages

The constituents

The symbols defined

in this package


Some scenarios

Some scenarios

  • Creating a simple test application, using some existing packages.

    1> cd ...

    2>edit requirements

    use Atlas v1

    use Mylib v2

    application myapp A.cxx B.cxx C.cxx

    3> cmt config# to be done only once in the package’s life

    4>edit source files here

    5> gmake

    6> myapp.exe

    7> back to 4


Some scenarios1

Some scenarios

  • Creating a plain package

    1> cmt config A v1 dev-area # to be done only once in the package’s life

    2> cd dev-area/A/v1/mgr

    3> edit requirements

    use Atlas v1

    use Mylib v2

    application myapp A.cxx B.cxx C.cxx

    4> edit source files into ../src

    5> gmake

    6> ../${CMTCONFIG}/myapp.exe

    7> back to 4 (or 3)


Some scenarios2

...Some scenarios

  • Selecting cooperating projects

    > setenv CMTPATH projectA:projectB:projectC


Some scenarios3

...Some scenarios

  • Iterative integration

    >edit use statements within the requirements

    use Mylib v2r1

    > source setup.csh

    > gmake

    > run


Some scenarios4

...Some scenarios

  • Package evolution

    > cd dev

    > cmt checkout A

    > cd A/v1/mgr

    > source setup.csh

    > gmake

    > change source files

    > test

    > cvs commit

    > cd ../

    > cvs tag v1r1

    > cvs release -d v1


Some scenarios5

...Some scenarios

  • Building domain packages

    • This is an interface package only containing a set of use statements towards a selection of versions for the packages belonging to a given conceptual domain

      • simulation

      • reconstruction

      • visualisation

    • A user of the simulation domain will simply use one given version of the simulation interface package, which automatically provides by transitivity (or inheritance) the appropriate selection of versions of all the simulation-related packages.

    • All configuration parameters defined in these packages are therefore inherited through this domain package.


Domain packages

Domain packages

  • The global “project” package

    1> cmt config Atlas v1

    2> cd public-area/Atlas/v1/mgr

    3> edit requirements

    use CxxFeatures v1r3

    use CLHEP v1r4

    use Simulation v1

    use Reconstruction v2

    use ...

    user package:

    use Atlas v1


The services

The services

  • Parameter monitoring

    cmt show macro xxx show a particular macro

    cmt show macros show all macros

    cmt show constituents show all constituents

    cmt show sets show all env. variables

  • Environment generation

    cmt config install a package

    cmt build msdev generate MSDev.Studio files

    cmt build readme generate README.html

    cmt checkout checkout a package from CVS

  • other

    cmt broadcast cmd iterate a command over the use chain.


The requirements file

The requirements file

  • General syntax

    packagename

    setname“default value”[tag“value”]…

    aliasname“default value”[tag“value”]…

    macroname“default value”[tag“value”]…

    applicationnamesource-file…

    librarynamesource-file…

    document generator name source-file …

    tagname tag-name…

    include_dirspath…

    setup_scriptname…

    cleanup_scriptname…

    etc...


The requirements file examples

The requirements file, examples

And variants for

Linux or HP

Define an environment variable

package CLHEP

set CLHEPHOME "[email protected]/CLHEP/dev" \

Linux "[email protected]/CLHEP" \

hp_ux102 "[email protected]/CLHEP"

macro CLHEP_cppflags "-DCLHEP_MAX_MIN_DEFINED -I$(CLHEPHOME)/include"

macro CLHEP_linkopts "-L$(CLHEPHOME)/lib -lCLHEP -lm" \

hp_ux102 "-L$(CLHEPHOME)/lib -lCLHEP-aCC -lm"

path_append LD_LIBRARY_PATH "${CLHEPHOME}/lib"

Extends the C++ flags for all client packages

Will be linked by all client applications

Needed when shared libraries are used


The requirements file examples1

The requirements file, examples

package CxxFeatures

set CXXFEATURESHOME “${SRT_DIST}/${SRT_VERSION}/Utilities/CxxFeatures”

include_dirs ${CXXFEATURESHOME}/.srt/${SRT_TARGET} \

${CXXFEATURESHOME}

use CLHEP v1r3

use STL v1

Define additional include search paths

used in dependency building

and in compilation

(for all client packages as well)

Transitive use statements

inherited by all client

packages


The requirements file examples2

The requirements file, examples

The CxxFeatures package is installed

under the Utilities directory.

package AgeToCxx

use CxxFeatures v0r3 Utilities

set AGETOCXXHOME “${SRT_DIST}/${SRT_VERSION}/Tools/AgeToCxx”

include_dirs ${AGETOCXXHOME}/.srt/${SRT_TARGET} ${AGETOCXXHOME}

make_fragment agetocxx_header

make_fragment agetocxx -suffix=cxx \

-dependencies \

-header=agetocxx_header

public

macro agetocxx \

"${SRT_DIST}/${SRT_VERSION}/installed/${SRT_TARGET}/bin/agetocxx"

The agetocxx fragment will be

used to generate C++ code

from Age files.

The dependency builder

will be applied to age files.


The requirements file examples3

The requirements file, examples

package Cm

use CSet v2r5

set CMDOMAIN "LAL” Virgo “Cascina”

alias cm "${CMROOT}/${CMTCONFIG}/cm.exe"

macro Cm_linkopts "-L$(CMROOT)/$(Cm_tag) -lCm -lm" \

LynxOS "$(CMROOT)/$(Cm_tag)/libCm.a -lnetinet -lrpc -lm"

macro_append cflags " -Dunix ”

# The Cm constituents.

library Cm -OS9 CmConnect.c CmMessage.c Cvt.c CmTransaction.c \

CmHandle.c

application NameServer -OS9 NameServer.c

application cm cm.c

The CMDOMAIN environment variable

will get different values

on different sites.

Client packages will link to the

library on all supported plateforms.

The constituents


Status

Status

  • Ported to

    • all Unix flavours (Dec, AIX, SGI, SunOS, Linux, HP-UX)

    • Windows 95/NT / MS Developer Studio

    • LynxOS (Cetia, CES)

  • Used by

    • the development team at LAL

    • the Virgo experiment (http://www.virgo.infn.it) (Lapp Firenze Frascati IPN-Lyon Napoli LAL ESPCI Perugia Pisa Roma)

    • the LHCb and Atlas experiments

    • the NEMO experiment (http://www.lal.in2p3.fr/NEMO/nemo.html) (France, Russia, INEL MHC Finland Ukraine Praha)

    • the AUGER experiment (http://wwwlpnhep.in2p3.fr/auger/welcome.html)


  • Login