Software Construction tools¶
Meeting was on 2009-9-8. Adam L, Marc M, Marc P, Kurt B, Ron R, Jim K.
CET met with Adam's REX group to discuss approaches to solving the "build and release" problem.
This meeting served two purposes: to understand what we (both groups) will say or what stand we
will make at the 2009-9-9 NUCOMP meeting, and what are we going to do about the "build and release" problem.
First we defined the problem. The problem is that we need a set of tools that is CD supported, maintained,
recommended, and used for doing several aspects of software development, namely
- tools for compiling applications and libraries * examples: make, SRT, scons, cmake, scram, CMT, ant * issues: platforms supported, dedicated machines * properties: ability to add a compiler, change an external product version easily
- release and distribution
- external/internal product versioning and dependency tracking * examples: UPS, yum, rpm * issues: moving binaries to another machine, standard server for releases, packaging
- automation for running test, framework for constructing them * examples: c++unit, junit * issues: comparing results of program with known values * properties: component tests, integration tests, physics validation, user acceptance
- source management
- examples: SVN, CVS, git * issues: central servers, security
- project tracking
- feature requests, milestones, effort estimates, wiki, downloads * examples: redmine, TRAC * issues: security, use of issue tracking
Nearly all of these have two areas we need to address: deployment of the tool and use of the tool. Deployment
means where the tool runs to do its job (centrally perhaps and on a given set of machines). Use means
configuring it and writing the specification files.
Here are some of the questions that need to be addressed by a chosen "build" product.
- integration with runtime environment? (how much is the development env bound to the runtime env?) * how easy is it to use on a disconnected laptop or university machine * how hard is it to add a compiler or create a new mode of compilation e.g. profiling build?
We need a requirements document with use cases.
We need a list of problems with other systems.
The document will start with three
sections: problem and purpose, terms and pieces involved, descriptions and examples of pieces, use cases or scenarios, current state of affairs,
and responsibilities of the various people/groups involved. The three we can start with are the problem, the pieces, and the descriptions.
Marc M - will draft a document that explains our goals and direction.
We should be choosing one product to learn, know, and love from each of the above categories.
Marc M wants to automate the creation of repositories through redmine. He has also hooked it into the lab ldap server to access passwords and