Unknown macro: {style}
span:opt
Unknown macro: {background-color}
th
Unknown macro: {background-color }
td
Unknown macro: {valign }
tr
Unknown macro: {valign }
span.call
Unknown macro: {background-color }
td.call
Unknown macro: {font-weight}
td.name
Unknown macro: {font-weight}
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
Unknown macro: {highlight} like this
. Functions or parts of functions which are desirable but not immediately required are indicated [like this] in the Description section.
CVS, Package Management
Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {th} Name
Unknown macro: {th} Description
Unknown macro: {th} SCons
Unknown macro: {th} NPMS
Unknown macro: {th} Stnd
Unknown macro: {td}
Unknown macro: {highlight} Package checkout
Unknown macro: {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.
Unknown macro: {td}
Unknown macro: {td} Working
Unknown macro: {td}
Unknown macro: {tr}
Unknown macro: {td}
Unknown macro: {highlight} Limited recursive checkout
Unknown macro: {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.
Unknown macro: {td}
Unknown macro: {td} Working
Unknown macro: {td}
Unknown macro: {td}
Unknown macro: {highlight} Dependency tree
Unknown macro: {td} Given a package, determine all packages it depends upon.
Unknown macro: {td}
Unknown macro: {td} Working
Unknown macro: {td}
Unknown macro: {tr}
Unknown macro: {td}
Unknown macro: {highlight} Find tags
Unknown macro: {td} Given a package, return list of its CVS tags [of a particular syntactic form]
Unknown macro: {td}
Unknown macro: {td} Planned
Unknown macro: {td}
Requirements on Requirements File Replacement
Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {th} Name
Unknown macro: {th} Description
Unknown macro: {th} SCons
Unknown macro: {th} NPMS
Unknown macro: {td} Inter-package dependence
Unknown macro: {td} Ability to express dependence on other packages, optionally with version (=CVS tag) specification
Unknown macro: {td}
Unknown macro: {td} Not needed
Unknown macro: {tr}
Unknown macro: {td} Macro/include
Unknown macro: {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.
Unknown macro: {td}
Unknown macro: {td} Planned
Unknown macro: {td} Per-target dependence
Unknown macro: {td} [Ability to specify dependence of individual target on other targets, both within the package under consideration or external to it.]
Unknown macro: {td}
Unknown macro: {td} Working
Unknown macro: {tr}
Unknown macro: {td} Per-operation dependence
Unknown macro: {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.]
Unknown macro: {td}
Unknown macro: {td} Not needed
Configure, build
Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {th} Name
Unknown macro: {th} Description
Unknown macro: {th} SCons
Unknown macro: {th} NPMS
Unknown macro: {td}
Unknown macro: {highlight} Configure
Unknown macro: {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.
Unknown macro: {td}
Unknown macro: {td} Not needed
Unknown macro: {tr}
Unknown macro: {td}
Unknown macro: {highlight} Single package build, recursive build
Unknown macro: {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']
Unknown macro: {td}
Unknown macro: {td} Working
Unknown macro: {td} Libraries
Unknown macro: {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.
Unknown macro: {td}
Unknown macro: {td} Planned
Export/Install, Run
Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {th} Name
Unknown macro: {th} Description
Unknown macro: {th} SCons
Unknown macro: {th} NPMS
Unknown macro: {td} Install
Unknown macro: {td} The output of the build system should be in a form suitable for packaging for export and remote installation.
Unknown macro: {td}
Unknown macro: {td} In Progress
Unknown macro: {tr}
Unknown macro: {td}
Unknown macro: {highlight} Run
Unknown macro: {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.
Unknown macro: {td}
Unknown macro: {td} Planned/Not needed
Developer Support
Unknown macro: {table}
Unknown macro: {tr}
Unknown macro: {th} Name
Unknown macro: {th} Description
Unknown macro: {th} SCons
Unknown macro: {th} NPMS
Unknown macro: {td} Path management
Unknown macro: {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.
Unknown macro: {td}
Unknown macro: {td} Planned
Unknown macro: {tr}
Unknown macro: {td} Configuration switching
Unknown macro: {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.]
Unknown macro: {td}
Unknown macro: {td} Working
Unknown macro: {td} Debugging
Unknown macro: {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).
Unknown macro: {td}
Unknown macro: {td} Planned
J. Bogart