Cleanup 17Sept2010 Closeout (Slimemold)¶
Generic table file and generic version file for CET products.
New repository cet_build_tools for housing this stuff. (including cmake modules and template UPS files)
Entire toy cmake example provided.
Standard build of gcc available.
Top cmake file corrected to properly provide header search paths for external products.
Note: Use of built products does not depend on cet_build_tools, but building does. (goal)
Unnecessary services identified and removed.
Service compressed into fewer source files (plugin files only in most cases).
Compilation failures addressed.
New gccxml for use with gcc 4.5.x.
New cet_lib for moving general tools out of Utilities directory to be used elsewhere.
Started to cleanup artapp and reorder initialization.
Better defined what a service is and categorized all the current services.
FHiCL-cpp completely integrated.
API design work complete (almost all).
Parameter set ID mostly done. Design work complete for the calculation of the SHA1.
"add parameterset" and "add value" to parameter set present.
Invalid parameter set ID problem is solved.
Produced a plan to move forward with support and development aligned with CMS package.
Tasks left to do¶
build and packaging¶
Documents on policies and procedures and rules doing development, building, installing, etc..
Good way to track tasks to do and tasks complete.
Need list of acceptable tools.
Note: proposal for development of this documentation. use wiki while not well understood, then switch to
document directory of a repository. issues are tool chain for building rendered document and which
formats are not desirable. Documentation packages and product packages (separate).
Need cmake modules:
- dealing with boost as a dependency * incorporate "flavor" into the generation process
Need to construct the c++0x helper package.
Need a tool for tracking tasks. Get Kurt to start an RTC server on oink.
A few more services need to be dealt with. (e.g. many services in one file).
Generated code is stilling causing compilation issues.
Need to review and cleanup all classes.h and reflex xml files.
Required service initialization of framework needs to be addressed. Might need modifications
of the service registry and movement of code from artapp to the EventProcessor.
Parameter set system initialization injection issue necessary for program startup. (removal of this needs to be addressed)
Plugin manager changes.
Startup of message facility in artapp needed to be addressed.
Namespace names chosen and applied.
Linking step needs to be done (libraries).
Tests: First throw out tests that test nothing.
Need a registry for parameter sets. This is for nesting and quick look-up.
Support for all native C++ types and user extensibility version of get/put in parameter set needs completion.
Rearrange build/directory structure to match group standards(include of headers fhicl/xxxx.h as a developer does not work)
Persistence of parameter sets needs to be solved.
Documentation of the SHA1 method of calculation needs to be completed.
FileInPath needs to be addressed. This is a utility that probably needs to be moved to cetlib.
The header describes this feature like this:
006 /// Find a non-event-data file, given a relative path. 007 008 /// FileInPath knows how to take a string, interpreted as a relative 009 /// path to a file, and to interpret using the "standard CMS 010 /// non-event-data file searching mechanism".
Estimate of completion¶
Next art fest last week of September.
Linking is issue.
Redesigned sections are an issue.
Need two hour meeting for creation of tasks for plugin manager work and possible completion of design work (at least more thorough documents than are present now. Possibly next Wednesday afternoon at 2:30pm.
Jim will ask Erik for a 6 hour session on laying out the whole project and tasks.
Backup plan is gcc 4.3.x for the compiler.
Not likely to have an alpha release before the end of October.
Refocus Fri 11:30 meeting by end of the month to be art focused.
Suggestions for improvement¶
- whiteboards * close but separate work area for subgroups * bigger group of people at 100% (3 at 100% this time, 5 at 100% last time) * three days * better advanced planning * less wondering from the main theme or work task * secretarial role for recording (tool or process could help here) * more desks * tasks switching to be less because of other work (biggger issue for development time)
- productive work started more quickly than last * accessibility of experts for consultation
co-development of products support? no. Separate packages using installed areas for dependencies.
Need a docdb process document posted by the end of November.
Service definition refinement: factory creation and management of object need separation? Not all services need to be plugins.Marc and I identified the following areas that need work:
- Starting / Services
- Parameter sets for running
- I/O ROOT - what we have, the parameters set, revamp of the I/O system
- Plugin manager
The ramification (effect) of design or software changes must be given some thought. This mostly involves talking group members about possible issues.
All members of the group should be willing to make changes to packages. Ownership is shared.
No package is complete: changes in features and design will be necessary as the package matures.
Need to record current rules (behavior), constraints, decision, but be able to make changes to any of them on a timely basis.