- Use the same VERSION file format as rtems-tools so a common release
generation can be used.
- The version.py is almost the same as rtems-tools. There are some
minor differences, one is the RTEMS version is present in this
file while rtems-tool uses config/rtems-release.ini.
Updates #3822
The orphans check lets you see which configuration and build set
files in the RSB are not referernced. You can audit the list and
remove any configuration files not being used. Top level
build set files are included so you need to becareful not to
remove something that is valid and useful. To run:
$ ./source-builder/sb-check --check-orphans
The building of 3rd party packages for an RTEMS BSP requires a valid
BSP so the standard method to download the source for releasing does
not work. This change adds support to allow this. The RTEMS BSP support
will not generate an error is no BSP or tools are provided or found.
The change addis logic operators to the %if statement so you can '||'
to 'or' and '&&' to 'and' logic expressions.
A new %log directive has been added to clean up the messages.
A new %{!define ...} has been added to aid checking within logic
expressions.
All command line --with/--without now appear as macros.
Add version.version to get just the RTEMS major and minor version.
Some pkg-config issues have been resolved.
Closes#2655.
Add support to release the RSB by adding the VERSION file. The file
is a single line with the version.
Fix the reports to include the version. Update the INI file
support to include the details of the build.
Show the GIT or released version when the command starts.
Closes#2480.
Set up the rules to manage the separate host and build setting to
allow a Canadian cross to complete.
Update the scripts to move the build directory and host/build
flags into the defaults so they are common for all build
configurations.
To support building snapshots and pre-release source the defaults
has been refactored. The defaults have been moved to a stand alone
file and a macros.py module added. This modile abstracts the
old default dictionary turning it into a class. The macros
class can load macros from a file therefore the defaults have
been moved to a stand alone file.
The use of defaults has been removed from the project. The only
case where it is used in the options where the defaults are read
from a file. Macros are used everywhere now.
The defaults.py has been moved to the option.py and the separate
options and defaults values has been moved to a new pattern. When
constructing an object that needs macros and options if the macros
passed in is None the defaults from the options are used. This makes
it clear when the defaults are being used or when a modified set of
macros is being used.
The macros class support maps. The default is 'global' and where all
the defaults reside and where configuratiion file changes end up.
Maps allow macros to be read from a file and override the values
being maintained in the 'global' map. Reading a macro first checks
the map and if not present checks the 'global' map.
The addition of maps to the macros provides the base to support
snapshots and pre-release testing with standard configurations.
This functionality needs to be added. It works by letting to
specify a snapshot with:
source0: none, override, 'my-dist.tar.bz2'
and it will be used rather the value from the standard configuration.
With a build set you need to also specify the package these macros
are for. The maps provide this.
