Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin
Wiki Markup
{style}
span:opt {background-color: #808080;}
th {background-color : #40c0c0;}
td {valign : top}
tr {valign : top}
span.call {background-color : #c0c0ff; }
td.call {font-weight: bold; background-color : #c0c0ff; }
td.name {font-weight: bold;}
{style}

Functional Requirements for Package Management/Build System

See tables below for a detailed list of required and desired properties and functions for any replacement of CMT. Most come from the Requirements/Goals section of the main CMT Action Committee Confluence page. The tables may be used as checklists for the two proposed replacements, identified as SCons and NPMS. SCons is meant as shorthand for SCons Enhanced; that is, SCons plus additions written locally. Where appropriate the tables allow for checking off a requirement by implementing a standalone solution (Stnd), independent of (and callable by) both SCons and NPMS. Functions which should be callable by one or more clients (RM, MRStudio, individual developer) are indicated

Wiki Markup
{highlight:#c0c0ff;}like this
{highlight}
. Functions or parts of functions which are desirable but not immediately required are indicated [like this] in the Description section.

CVS, Package Management

Wiki Markup
{table:cellpadding=4}
{tr}
{th}Name
{th}
{th}Description
{th}
{th}SCons
{th}
{th}NPMS
{th}
{th}Stnd
{th}
{tr}
{td}
{highlight:#c0c0ff;}{*}Package checkout*
{highlight}
{td}
{td}Check out requested tag (may have value HEAD) of a single package from CVS, installing in user's workspace in a manner consistent with current directory/subdirectory conventions.
{td}
{td}  
{td}
{td} Working
{td}
{td} 
{td}
{tr}
{td}
{highlight:#c0c0ff;}{*}Limited recursive checkout*
{highlight}
{td}
{td}Given a _container package_ (one that refers to a list of other packages by name and CVS tag), check out all packages it refers to.
{td}
{td} 
{td}
{td}Working
{td}
{td} 
{td}
{tr}
{td}
{highlight:#c0c0ff;}{*}Dependency tree*
{highlight}
{td}
{td}Given a package, determine all packages it depends upon.
{td}
{td} 
{td}
{td}Working
{td}
{td} 
{td}
{tr}
{tr}
{td}
{highlight:#c0c0ff;}{*}Find tags*
{highlight}
{td}
{td}Given a package, return list of its CVS tags \[of a particular syntactic form\]
{td}
{td} 
{td}
{td}Planned
{td}
{td} 
{td}
{table}

Requirements on Requirements File Replacement

Wiki Markup
{table:cellpadding=4}
{tr}
{th}Name
{th}
{th}Description
{th}
{th}SCons
{th}
{th}NPMS
{th}
{tr}
{td}{*}Inter-package dependence*
{td}
{td}Ability to express dependence on other packages, optionally with version (=CVS tag) specification
{td}
{td} 
{td}
{td}Not needed
{td}
{tr}
{td}{*}Macro/include*
{td}
{td}A way to express common forms in a single place which may be referred to by many packages. Should have a way to supply arguments.
{td}
{td} 
{td}
{td}Planned
{td}
{tr}
{td}{*}Per-target dependence*
{td}
{td}\[Ability to specify dependence of individual target on other targets, both within the package under consideration or external to it.\]
{td}
{td} 
{td}
{td}Working
{td}
{tr}
{tr}
{td}{*}Per-operation dependence*
{td}
{td}\[Ability to specify that a particular dependence is in effect at compile time, at link time or at load time. Less interesting, maybe entirely redundant, if we already have per-target dependence specification.\]
{td}
{td} 
{td}
{td}Not needed
{td}
{table}

Configure, build

Wiki Markup
{table:cellpadding=4}
{tr}
{th}Name
{th}
{th}Description
{th}
{th}SCons
{th}
{th}NPMS
{th}
{tr}
{td}
{highlight:#c0c0ff}{*}Configure*
{highlight}
{td}
{td}If a configure step ("establish environment, get ready to build") is needed at all, it should be callable and there should be a recursive variant. Whether configure options are set by an explicit operation or are inferred (e.g., from environment variables) it must be possible to indicate OS, compiler, debug, etc.
{td}
{td} 
{td}
{td}Not needed
{td}
{tr}
{td}
{highlight:#c0c0ff}{*}Single package build, recursive build*
{highlight}
{td}
{td}Support request to build specified package and all it depends upon. \[Would be better still if one could alternately specify 'build only current package; if external inputs are absent, stop immediately with error'\]
{td}
{td} 
{td}
{td}Working
{td}
{tr}
{td}{*}Libraries*
{td}
{td}Build one or both of static library and shareable, as specified in requirements-replacement file. Further distinguish between Gaudi component and other shareables. For non-component shareable on Windows, make all public members (function members and data members) available at link time to other packages.
{td}
{td} 
{td}
{td}Planned
{td}
{table}

Export/Install, Run

Wiki Markup
{table:cellpadding=4}
{tr}
{th}Name
{th}
{th}Description
{th}
{th}SCons
{th}
{th}NPMS
{th}
{tr}
{td}{*}Install*
{td}
{td}The output of the build system should be in a form suitable for packaging for export and remote installation.
{td}
{td} 
{td}
{td}In Progress
{td}
{tr}
{tr}
{td}
{highlight:#c0c0ff}{*}Run*
{highlight}
{td}
{td}Run an application with supplied arguments. Any part of the build environment needed at run time should be transparently available then, without special action by the client.
{td}
{td} 
{td}
{td}Planned/Not needed
{td}
{table}

Developer Support

Wiki Markup
{table:cellpadding=4}
{tr}
{th}Name
{th}
{th}Description
{th}
{th}SCons
{th}
{th}NPMS
{th}
{tr}
{td}{*}Path management*
{td}
{td}It should be easy for developers to
* establish a local writable working directory
* develop against an existing read-only release in such a way that local packages take precedence over those in the release at compile, link and run time.
{td}
{td} 
{td}
{td}Planned
{td}
{tr}
{td}{*}Configuration switching*
{td}
{td}It should be easy for a developer (or for a GUI application, on behalf of the developer) to switch from one environment to another. Here _environment_ might include items such as debug/release setting and path as in previous item. \[It should be possible to establish and use distinct environments simultaneously from different processes.\]
{td}
{td} 
{td}
{td}Working
{td}
{tr}
{td}{*}Debugging*
{td}
{td}All tools necessary for debugging an application built by the system should be available. For Windows this means project/solution files so the application can be run in Visual Studio (and patched from there?). For unix systems it should be possible to run applications from emacs/gdb or DDD (probably doesn't require anything special of build system beyond reasonably portable and self-contained run-time environment for applications).
{td}
{td} 
{td}
{td}Planned
{td}
{table}

J. Bogart