Difference between revisions of "The XCDL.py Software Requirements Specifications"
From XCDL (eXtensible Component Definition Language) Wiki
m (→Specific requirements) |
m (→Specific requirements) |
||
| Line 42: | Line 42: | ||
* must not require special/non portable tools on the build platform; Python is prefered, Java is accepted | * must not require special/non portable tools on the build platform; Python is prefered, Java is accepted | ||
* must allow multiple toolchains | * must allow multiple toolchains | ||
| − | * must be C++ centric and must handle C++ dependencies automatically (obviously) | + | * must be C/C++ centric and must handle C/C++ dependencies automatically (obviously) |
* should provide as much help as possible to specific steps like flash programming, debug, profiling | * should provide as much help as possible to specific steps like flash programming, debug, profiling | ||
* might provide support for documentation generating tools (Doxygen) | * might provide support for documentation generating tools (Doxygen) | ||
Revision as of 01:26, 12 December 2012
Contents
Introduction
Purpose
This document is intended for software architects, designers, and developers, and should provide with the necessary input required during the design, implementation and maintenance of the XCDL framework.
Scope
This document refers to the XCDL configuration definitions and the associated build process.
Definitions and acronyms
- CDL - Configuration Definition Language, the configuration mechanism used by eCos
- XCDL - an extensible, XML based, configuration mechanism, inspired by CDL
References
Overview
Overall description
Product perspective
Product functions
User characteristics
Constraints
Assumptions and dependencies
Specific requirements
(To be ordered)
- must allow integration of source code from multiple repositories, even different svn/git/hg/etc
- must allow multiple variants (build configurations) for a project (Debug/Release); the build configs may run on identical or different hardware (different boards, different processors, different amounts of ram/flash, etc); an example of such a config was used for the Metrilog SDI-12 sensors, where the Debug config used a larger AVR than the Release.
- must store the complete build config in its own files (probably XMLs, but inspired from eCos CDT files)
- must run from the command line
- must allow integration with Eclipse CDT
- should allow integration with Xcode
- might allow integration with other IDEs like Visual Studio, NetBeans
- must not require special/non portable tools on the build platform; Python is prefered, Java is accepted
- must allow multiple toolchains
- must be C/C++ centric and must handle C/C++ dependencies automatically (obviously)
- should provide as much help as possible to specific steps like flash programming, debug, profiling
- might provide support for documentation generating tools (Doxygen)
- must provide support for testing (continuous integration)
- must provide support for custom build steps, using external tools (for example for adding a binary checksum, custom metadata, etc)
- should be reasonably short
