On 21/07/2019 04:08, Chris Johns wrote:
On 19/7/19 11:41 pm, Joel Sherrill wrote:
On Fri, Jul 19, 2019 at 4:33 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de
<mailto:sebastian.hu...@embedded-brains.de>>
wrote:
Hello,
I worked a bit with Doorstop and found the YAML file quite interesting.
The file format is not without problems:
https://arp242.net/yaml-config.html
However, for simple configuration stuff it is easy to write, read and
process. Changes can be reviewed well in Git (content is spread over
lines).
I experiment currently a bit with using a YAML file to define the RTEMS
build.
How should BSPs be identified in the future? Should a BSP name be unique
across architectures or do we want to use an "arch/bsp" tuple?
Yes.:)
Yes and +1.
This is the format I have standardised on for everything but building RTEMS, ie
rtems_waf which means libbsd. The kernel has the --target triplet and the bsp.
Ok, good.
Some background information about what I am experimenting. To make the
ECSS standard happy, we have to deliver a Software Configuration File
(SCF) for example. This overlaps a bit with the information necessary to
build RTEMS. I would like to concentrate the information in Doorstop
maintained files and generate different outputs based on the intended
usage, e.g. an SCF or build files (Makefile, waf). Another example is
that we may have a requirement like this: The compiler flags for the XYZ
BSP shall be "-O2 -g -mleon3". We could add the compiler flags to a
BSP-specific configuration item which has a "cflags: -O2 -g -mleon3"
attribute. We can use this attribute to generate a human readable
requirement in an Software Requirements Specification (SRS) and the
build file. The compiler flags just have one master data, everything
else is derived and produced by tools.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
